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Abstract 


The National Aeronautics and Space Administration (NASA) Armstrong Flight Research Center Small 
Unmanned Aerial Vehicle (SUAV) Automatic Ground Collision Avoidance System (Auto GCAS) project 
demonstrated several important collision avoidance technologies. First, the SUAV Auto GCAS design 
included capabilities to take advantage of terrain avoidance maneuvers flying turns to either side as well as 
straight over terrain. Second, the design also included innovative digital elevation model (DEM) scanning 
methods. The combination of multi-trajectory options and new scanning methods demonstrated the ability 
to reduce the nuisance potential of the SUAV while maintaining robust terrain avoidance. Third, the Auto 
GCAS algorithms were hosted on the processor inside a smartphone, providing a lightweight hardware 
configuration for use in either the ground control station or on board the test aircraft. Finally, compression 
of DEM data for the entire Earth and successful hosting of that data on the smartphone was demonstrated. 
The SUAV Auto GCAS project demonstrated that together these methods and technologies have the 
potential to dramatically reduce the number of controlled flight into terrain mishaps across a wide range of 
aviation platforms with similar capabilities including UAVs. general aviation aircraft, helicopters, and 
model aircraft. 


Nomenclature 


ACAT 

Automatic Collision Avoidance Technology 

AFRC 

Armstrong Flight Research Center 

AGL 

above ground level 

ART 

available reaction time 

Auto GCAS 

Automatic Ground Collision Avoidance System 

CFIT 

controlled flight into terrain 

CDTM 

Compressed Digital Terrain Maps 

CONUS 

contiguous United States 

COTS 

commercial off-the-shelf 

DEM 

digital elevation model 

DR 

Discrepancy Report 

DROID 

Dryden Remotely Operated Integrated Drone 

DSOC 

Defense Safety Oversight Council 

DTED 

Digital Terrain Elevation Data 

EGI 

embedded GPS/INS 

EAFB 

Edwards Air Force Base 

FRRP 

Fighter Risk Reduction Project 

GCAS 

Ground Collision Avoidance System 

GCO 

ground control operator 

GEDACS 

Global Elevation Data Adaptive Compression System 

GPS 

global positioning system 

HIL 

hardware -in-the -loop 

HOTAS 

Hands On Throttle -And-Stick 

HUD 

head-up display 

HWY 

highway 

INS 

inertial navigation system 

KIAS 

knots indicated airspeed 

KTAS 

knots true airspeed 

MSL 

mean sea level 
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NASA 

National Aeronautics and Space Administration 

NAV 

buffer to account for GPS navigation accuracy 

NED 

National Elevation Dataset 

NGA 

National Geospatial-Intelligence Agency 

PARS 

Pilot Activated Recovery System 

PCC 

Piccolo 11 autopilot command center 

PVI 

pilot-vehicle interface 

RPV 

remotely piloted vehicle 

SD 

secure digital 

SRTM 

Shuttle Radar Topography Mission 

SUAV 

small unmanned aerial vehicle 

TCB 

terrain clearance buffer 

TM 

telemetry 

TPA 

trajectory prediction algorithm 

UAS 

unmanned aircraft system 

UAV 

unmanned aerial vehicle 

UI 

user interface 

UIO 

user interface operator 

WGS84 

World Geodetic System 1984 

WP 

waypoint 

a 

half angle 

P 

half width 

B 

base width 


Introduction 


Automatic Ground Collision Avoidance Systems (Auto GCAS) have been demonstrated in research 
and development flight-testing on multiple projects for over 25 years. Most early Auto GCAS development 
took place during the Advanced Fighter Technology Integration (AFTI) F-16 airplane (General Dynamics, 
now Lockheed Martin, Bethesda, Maryland) project in the late 1990s (ref. 1). The F-16 Fighter Risk 
Reduction Project (FRRP) was completed in 2010 and matured Auto GCAS technology to the point where 
it was ready to be integrated with production F-16 hardware and software (ref. 2). A production version of 
Auto GCAS was recently flight-tested on United States Air Force (USAF) F-16 airplanes with deployment 
to operational squadrons beginning in 2014 (ref. 3). A derivative implementation of Auto GCAS has also 
been flight-tested on the F-22 airplane (Lockheed Martin, Bethesda, Maryland) (ref. 4). An Auto GCAS 
implementation has also been planned for the F-35 airplane (Lockheed Martin, Bethesda, Maryland) after 
initial operational capability. All of these projects were components of the broader Automatic Collision 
Avoidance Technology (ACAT) program under the guidance of the Defense Safety Oversight Council 
(DSOC). 

The DSOC has concluded that the comprehensive 75-percent mishap reduction rate mandated by the 
Secretary of Defense (refs. 5 and 6) cannot be achieved without the widespread implementation of Auto 
GCAS. Manual terrain avoidance systems warn the pilot and rely on pilot reactions to avoid terrain. Such 
systems have already been implemented on various platforms with mixed success. However, Controlled 
Flight Into Terrain (CFIT) mishaps continue to occur on many platforms within the Department of Defense 
(DoD). Controlled Flight Into Terrain mishaps also continue to result in an alarming number of general 
aviation fatalities every year. 
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The primary objections to Auto GCAS have been perceived nuisance potential and perceived cost. 
Nuisance potential is a valid concern but specific design requirements to minimize nuisance activations can 
be an integral part of any system. Cost is also a valid concern, but on many platforms the cost of fleet-wide 
implementation of Auto GCAS can be recovered by the prevention of a single CFIT mishap (ref. 7). 

The DSOC has been highly motivated to find low-cost Auto GCAS alternatives with applications across 
widely varying aircraft types. As a result, the DSOC funded a limited-scope design and flight-test effort to 
transition Auto GCAS technologies from the previous F-16 system to a small unmanned aerial vehicle 
(SUAV). An overall goal of the SUAV Auto GCAS project was to enhance the proven technologies within 
Auto GCAS whenever practical, while at the same time exploring techniques to achieve significant cost 
savings. 

This report has two primary goals: 

• Communicate the design concepts and flight-test results from the SUAV Auto GCAS project; 
and 

• Compare SUAV Auto GCAS design concepts to those used on other successful Auto GCAS 
projects (primarily the F-16) with the intent of helping future projects identify tradeoffs and 
determine which concepts can be tailored to best serve a given platform. 

One of the most important lessons learned from recent Auto GCAS projects has been that there are 
many design approaches that will work. However, there will always be important tradeoffs that must be 
understood to improve the likelihood that a given design will be successful. 

This report identifies a few of the most significant tradeoffs and design choices. Design concepts that 
work on a low-speed UAV may not be best for a high-speed fighter, and vice versa. As Auto GCAS is 
applied to a broader spectrum of platforms, such as transports, general aviation, and helicopters, it is 
expected that design concepts will continue to evolve. In spite of differences in aircraft type, it is also 
expected that a modular Auto GCAS architecture will be applicable regardless of platform. 

The SUAV Auto GCAS project successfully demonstrated many important collision avoidance 
technologies. The foremost of these demonstrations included: 

• Auto GCAS testing with multiple avoidance maneuvers including turns to either side; 

• Testing of digital terrain scanning techniques determined directly from the predicted trajectory; 

• In-flight -testing of highly compressed digital elevation maps; 

• In-flight -testing of digital elevation maps that had been customized to reflect tighter tolerances 
in some areas, and relaxed tolerances in other areas; 

• In-flight -testing of Auto GCAS on a UAV; and 

• Auto GCAS algorithms were hosted on a smartphone during flight tests. 

Since one of the motivations for this report is to assist design choices on future projects, 
recommendations are introduced as important design aspects are described. The relevant SUAV Auto 
GCAS flight-test results may not be described in detail until later in the report. 

The specific implementation techniques used on the SUAV project were accomplished to provide an 
inexpensive test bed for the new Auto GCAS technologies, and were not intended to be a direct path to a 
production UAV implementation. Therefore, any production implementation of Auto GCAS on a UAV 
would still need to be customized for the intended platform. 

For example, an appropriate level of redundancy would be essential for production UAV 
implementation. This SUAV project was essentially single-thread, which was practical for this research test 
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bed because a safety pilot was always ready to take control if the Auto GCAS algorithm commanded an 
inappropriate aircraft response. A production UAV implementation of Auto GCAS would require the level 
of redundancy necessary to meet the requirements of that system. 

Using the smartphone to host the Auto GCAS algorithm was an implementation technique that was 
specific to this SUAV test bed demonstration. The smartphone posed specific challenges in terms of the 
need to use the Java™ (Oracle Corporation, Redwood Shores, California) programming language, the need 
to address timing aspects for real-time versus background tasks, and the need to utilize particular 
verification and validation techniques. This report does not address the smartphone-specific challenges. 
Although smartphones continue to be used for follow-on Auto GCAS projects, those are also considered 
test bed applications. A production application would require consideration of the host computer reliability 
as well as the abovementioned redundancy aspects. 

Note: This report uses wording consistent with the terminology used on the SUAV Auto GCAS and 
F-16 Auto GCAS projects at the time. An activation on SUAV Auto GCAS is called an “avoidance 
maneuver; ” an activation on F-16 Auto GCAS is called a “flyup ” maneuver. 

Research Objectives 


The original DSOC customer direction was to: 

• “Ensure interoperability between Auto GCAS functions and a small Unmanned Aircraft System 
(UAS); 

• Tailor F-16 Auto-GCAS algorithms to the Dryden Remotely Operated Integrated Drone 
(DROID) UAV platform; 

• Improve the Auto GCAS design where necessary to support UAS-class aircraft; 

• Implement Auto-GCAS algorithms on a palm-sized personal computer; 

• Demonstrate portability of Auto GCAS algorithms; 

• Flight-test auto GCAS on a small UAS; and 

• Provide regression level -of-effort for future platform integration.” 

The intent of the last listed item was to minimize the effort required to implement Auto GCAS onto 
future platforms. Most of the items were blended as sub-objectives into the final project objectives. 
Additional discussions with the customer resulted in the following top-level project objectives, as 
documented in reference 8. 

• Demonstrate the portability of the Auto GCAS algorithms; 

• Demonstrate and evaluate the Auto GCAS integrated with a UAS platform mimicking a generic 
medium-to-large UAV hosted in a ground-based implementation; 

• Demonstrate and evaluate the Auto GCAS integrated with a UAS platform mimicking a generic 
medium-to-large UAV hosted in an on-aircraft-based implementation; and 

• Identify attributes of the Auto GCAS design which are not easily ported to other aerial vehicles. 

These top-level project objectives provided more explicit focus on generic UAVs as a long-term 
application for this technology demonstration. Generic UAVs were selected for two reasons. First, UAVs 
are prime candidates for incorporation of an Auto GCAS. Second, the National Aeronautics and Space 
Administration (NASA) Armstrong Flight Research Center (AFRC) owned and operated a broad range of 
UAVs, including an MQ-9 Reaper (General Atomics, San Diego, California) and an RQ-4 Global Hawk 
(Northrup Grumman Corporation, Falls Church, Virginia). The NASA UAVs provided logical paths 
forward for future Auto GCAS research projects. 
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The first three top-level objectives were met. The fourth top-level objective was indirectly met; no Auto 
GCAS attributes were identified that would be difficult to port onto other aerial vehicles. 


Design Philosophy and Top-Level Requirements 


An Auto GCAS Requirements Guide has been established by the Air Force Research Laboratory 
(ref. 9). This guide provides a step-by-step process to help any Auto GCAS project develop specific 
requirements based on the mission and maneuvering capability of that platform. The Auto GCAS 
Requirements Guide also enables Auto GCAS developers to make independent decisions regarding each 
design aspect while considering the lessons learned over several decades of Auto GCAS development on 
multiple past projects. To date, this Requirements Guide has been used to influence design decisions on the 
following Auto GCAS projects: 

• F-16 Auto GCAS Fighter Risk Reduction Program; 

• Small UAV Auto GCAS ; 

• F-16 production Auto GC AS ; 

• F-35 production manual and Auto GCAS; and 

• General Aviation Ground Proximity Warning System (a California Polytechnic State University, 
San Luis Obispo, student design project). 

The initial SUAV Auto GCAS project requirements were intentionally kept flexible in order to 
maximize the potential return on investment for this research project. As trade studies were accomplished, 
detailed design requirements for each Auto GCAS subsystem were refined within design documentation 
(ref. 10). The fundamental top-level project requirements for the SUAV project are summarized in the 
following sections so that related projects can identify similarities and differences. 

Test Aircraft Requirements 

It was decided early on that the test aircraft would be a Dryden Remotely Operated Integrated Drone 
(DROID) already owned and operated at AFRC. The project team developed the following fundamental 
aircraft capability requirements that became integral to the project: 

• “Provide for cost effective system integration; 

• Dramatically different platform than an F-16 (in terms of performance, maneuvering capability, 
sophistication, commercial off-the-shelf (COTS) components availability, and the fact that it 
was unmanned); 

• Maneuvering authority sufficient to mimic a generic medium-to-large UAV (the DROID ’s 
slower top speed was judged acceptable for the puipose of this testing); 

• Pre-existing onboard autopilot capable of executing the “generic UAV” terrain avoidance 
maneuvers based on commands from the host computer. This included auto-throttle capability. 

• Aircraft modifiable to install host computer; 

• Onboard GPS/INS; 

• Autonomous control from the ground control van (waypoint tracking); 

• Direct control from a ground cockpit (similar to an RPV); 

• Direct line-of-sight control by a safety pilot (to be located near the prominent terrain features); 
with more maneuvering authority than the generic UAV imitation; and 

• Approximate 1-hr mission length (constrained by fuel and batteries).” 
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See figure 1 for a comparison of the DROID test aircraft and the F-16 used during the Auto GCAS 
FRRP. 



Figure 1. Comparison of F-16 and DROID. 

Ground Control Van Requirements 

The ground control van needed to be capable of supporting all of the test aircraft requirements listed 
above. Another fundamental requirement for the ground control van was that it could be successfully 
deployed to remote desert locations. 


Host Computer Requirements 

It was originally intended that the Auto GCAS algorithms be hosted in their entirety on a palm-sized 
personal computer. The intent was that the host computer could be installed on the SUAV without excessive 
gross weight impacts. 

During development it was determined that this requirement could be met using a smartphone based 
on the Android™ platform (Google Inc., Mountain View, California). That decision was made in order to 
demonstrate a low-cost alternative and to maximize portability for future applications on other aircraft, 
especially within general aviation. 

The project team also developed the fundamental host computer requirements which were: 

• Commonly available computational device; 

• Provide a growth path for follow-on projects; 

• Capability to interface with on-board autopilot and other system components in either 
“on-aircraft” or “on-ground” configurations; 

• Sufficient storage for all Auto GCAS algorithms including the necessary Digital Elevation Model 
(DEM) data and flight-test data; 

• Sufficient throughput for Auto GCAS algorithms to execute within an acceptable frame time 
while also recording the designated flight test data; and 
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• Develop a method to allow an operator to interface with the host computer to control Auto GCAS 
setup and options from the ground control van. 

From project inception, it was understood that these fundamental requirements would be met through 
ongoing design tradeoffs. It was already known that the smartphone storage capacity (32 GB) was more 
than sufficient to store all of the Auto GCAS algorithms and DEM data for the entire Earth at a resolution 
acceptable for aircraft with predominant missions at high altitude, while also including local maps at the 
higher resolution needed for an SUAV test mission. The primary design constraint related to storage 
capacity was that Auto GCAS data were only recorded at the initiation of each avoidance maneuver. 
By comparison, the F-16 had recorded Auto GCAS data throughout the flight, which was much more useful 
for assessing nuisance potential in situations in which flyups did not activate. 

It was known that the smartphone throughput capacity was sufficient to complete the basic Auto GCAS 
functions at a rate that was considered adequate. In addition, the requirement could also be met by including 
a forecast for time delay as part of the Auto GCAS algorithm. Therefore, compensation for a slower frame 
rate could be achieved by increasing the time delay within the avoidance maneuver prediction portion of 
the algorithm. In other words, avoidance maneuvers would happen sooner if the frame rate were slower. 
The primary design constraint related to throughput capacity was the rate at which flight -test data could be 
recorded without interfering with the basic Auto GCAS functions. 

It was also known that the on-ground configuration would increase the risk of loss of communication 
between the aircraft and the ground control van, as compared to the on-aircraft configuration. The 
on-ground configuration was implemented to evaluate Auto GCAS applications to future platforms that 
could not accept weight increase. The on-aircraft configuration was recognized as the more robust 
implementation and would be preferred for any future platform that could accept a small weight increase. 
Both configurations were designed and flight-tested in order to obtain a better understanding of the 
real-world performance. 

One of the original customer requirements was to “Tailor F-16 Auto-GCAS algorithms to the Dryden 
Remotely Operated Integrated Drone (DROID) UAV platform.” Part of the intent behind that requirement 
was to start with the actual F-16 Auto GCAS C ++ code and adapt that code as needed. However, after 
initiating SUAV Auto GCAS design work it became clear that the available documentation was insufficient 
to understand the F-16 approach to modularity and was insufficient for third-party tailoring of the algorithm. 
Once aware of those difficulties, the customer agreed that project goals could be achieved without using 
the F-16 code as a direct basis. 

It also became apparent that using C ++ code was not the best choice for implementation on a 
smartphone. The C ++ code had seemed to be the logical choice because of the F-16 reference model and 
because most of the project programmers were already very familiar with C ++ code. The C ++ code required 
a wrapper in order to run on the smartphone, but that interpreter did not include some of the required 
capability, such as trigonometric functions. Therefore it was decided to use Java™ because it was native to 
the smartphone and completely avoided the problems associated with trying to use the C ++ code. The skill 
of the main SUAV Auto GCAS programmer facilitated a very smooth transition to Java™. 

Avoidance Maneuver Performance Requirements 

The initial concept for this project was to re-host the previous F-16 flyup maneuver and adapt it to the 
maneuvering capability of the generic medium-to-large UAV. The F-16 flyup maneuver can be most simply 
described as “roll toward wings-level and pull at 5 g until clear of terrain.” The F-16 flyup maneuver was 
basically a maneuver flying straight over terrain after reaching wings-level. That type of maneuver worked 
reasonably well for the F-16, given the large amounts of kinetic energy that could be turned into altitude. 
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Not surprisingly, the simulated medium-to-large UAV had much more limited climb capability than 
did the F-16. Early design studies indicated that if a straight avoidance maneuver analogous to the F-16 
flyup was used with medium-to-large UAV climb performance, the avoidance needed to be initiated many 
thousands of feet prior to reaching tall terrain features. Avoidance maneuvers induced by distant mountains 
would be considered an extreme nuisance if the operator intended to turn away from the mountains long 
before reaching them. 

Based on that result, the design philosophy changed to incorporate the option for two turning avoidance 
maneuvers in addition to the straight maneuver. All three avoidance maneuvers were pre-defined to mimic 
typical medium-to-large UAV performance using the following autopilot command targets as requirements: 

• Climb and descent rate: 1000 fpm; 

• Bank angle: 40 deg; 

• Roll rate: 50 deg/s; and 

• Airspeed: 60 knots indicated airspeed (KLAS) (the middle of the DROID speed range). 

These values were not selected to precisely model a specific UAV, but were selected to approximate 
the general capabilities of medium-to-large UAVs. The DROID was capable of much higher maneuvering 
levels in each axis. 

The target airspeed of 60 KIAS was chosen somewhat higher than the airspeed for optimal turn radius 
of the DROID. This was primarily done to be more representative of the higher airspeeds typical for larger 
UAVs. 


Trajectory Prediction Requirements 

It was recognized early on that the existing simulation of the DROID was not very representative of the 
way the actual airplane flew. Updating the DROID simulation was considered out of scope for the SUAV 
Auto GCAS project, so the DROID simulation could not be used to help design the initial avoidance 
maneuver trajectory predictions. 

Since the avoidance maneuvers were constrained to three basic autopilot commands (climb, bank, 
speed), a high-fidelity simulation model of the DROID was not necessary. All of the information necessary 
for trajectory predictions was obtained directly from preliminary flight-testing of the three avoidance 
maneuvers (left, straight, right). That process is described in more detail in the “SUAV Auto GCAS ‘Predict 
Avoidance Trajectories’ Module” section below. 

The fundamental requirements for the trajectory prediction were to: 

• Use a trajectory prediction divided into three basic phases: a time-delay phase, a capture phase, 
and a steady-state phase. These phases are discussed in more detail in the “Generic ‘Predict 
Avoidance Trajectories’ Module” section below. 

• Use an adjustable time -delay phase to compensate for communications lag between components, 
and for changes to the basic frame rate. 

• Use adjustable parameters for the capture phase to reflect actual aircraft responses, such as roll 
onset rate and g-onset rate. 

• Use values during the steady-state phase that are sustainable by the aircraft and onboard autopilot. 

• Allow parameters to be functions of other variables so they can be tuned for any flight condition 
dependencies observed during flight-testing. 



In order to obtain the flight-test data necessary to tune the trajectory prediction, an additional 
fundamental requirement was to: 

• Implement a method to initiate avoidance maneuvers based on a manual command, independent 
of terrain proximity. 

Digital Elevation Model Data Requirements 

Many military Auto GCAS implementations use no active terrain sensors, so no radio frequency 
emissions were required. This differs from many terrain-following systems that often relied on 
forward-looking radar or radar altimeters. The only sensors used for Auto GCAS typically had already been 
installed for other purposes. 

The main SUAV Auto GCAS sensor was a standard blended GPS/1NS as already installed on the 
DROID. Similar blended GPS/INS units had already become common on a wide variety of aircraft types. 
A GPS/INS that is already installed for navigation applications does not need to be considered part of the 
cost for an Auto GCAS. The main Auto GCAS utilization of GPS/INS data was to accurately locate 
the aircraft longitude, latitude, and altitude over a matrix of DEM data. 

The intention from the beginning of this research project was that the project expand the concepts for 
using DEM data beyond the original F- 1 6 implementation (as discussed in references 2 and 3). In particular, 
the intent was to demonstrate and evaluate the DEM data compression and re-rasterization methodology 
developed by NASA in support of early Auto GCAS tradeoff studies for another fighter aircraft. The 
fundamental requirements for using DEM data were to: 

• Demonstrate the use of DEM source data from the National Elevation Dataset (NED). 
A description of the NED is contained in the section “Generic ‘Sense Terrain’ Module” below. 
Data from the NED had not been used on previous Auto GCAS projects. 

• Demonstrate the use of existing NASA DEM data compression techniques to store DEM data for 
the entire Earth with vertical and horizontal accuracy adequate to support air-superiority fighter 
missions. 

• Demonstrate the use of existing NASA DEM data lossless compression techniques to maintain 
high vertical and horizontal accuracy in the specific test areas to be used by the test aircraft. 

• Demonstrate that the compressed DEM data can be used in a real-time aviation environment. 

• Use a basic resolution for the re -rasterized DEM data of 3 arc-s (equivalent to the F-16). 

• Develop appropriate scan techniques for lateral escape terrain avoidance maneuvers. 

Flight-Test Analysis Support Requirements 

In addition to the system requirements for the overall SUAV Auto GCAS design (including data 
recording), two additional features were implemented to support flight-test analysis. These included: 

• Use of an off-the-shelf laser altimeter to provide an alternate source for AGL data; and 

• Use an off-the-shelf high-definition tail camera to capture clear detail of terrain proximity during 
flight tests. 


Flight-Testing as Part of the Design Process 


Several DROID characterization flights and portions of the first SUAV project flights were used as 
inherent elements of the SUAV Auto GCAS design process. Therefore, the design impacts obtained from 
those flights are included in the following system overview descriptions for each module. The remaining 
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SUAV project flights were more focused on the intended Auto GCAS development and evaluation and are 
discussed in the “Test Results” section below. 

Research System Overview 


The SUAV Auto GCAS research project consisted of three primary elements: the DROID, the ground 
control van, and the Android™ platform smartphone hosting the Auto GCAS Algorithms. Additional 
background on the overall design can be found in the SUAV System Design Document (ref. 10). 

Dry den Remotely Operated Integrated Drone (DROID) Test Aircraft 

The DROID test aircraft was part of a fleet of four similar aircraft owned by NASA AFRC and 
operated by the AFRC Model Shop. The DROIDs have been used for a variety of purposes including pilot 
training, as research project test beds, and as part of student outreach programs (ref. 11). 

The DROID was based on the Bruce Tharpe Engineering (Rogue River, Oregon) Modified Super Flyin’ 
King kit aircraft. The basic specifications were: 

• Wing span: 9 ft 8 in; 

• Total operating weight: 58 lb; 

• Power rating: 1 1 HP; 

• Maximum maneuvering speed (Vmax): 80 KIAS; and 

• Flight duration: 1.1 hr. 

The SUAV Auto GCAS project used DROID 2 (fig. 2) which included the following project-specific 
modifications: 

• Custom mounts for the Android™ platform smartphone; 

• Laser altimeter (built by Latitude Engineering, Tucson, Arizona); 

• High-definition video camera mounted on the tail; 

• Extra batteries; 

• Empennage stabilization support modification (wires were run from the vertical tail to the 
horizontal tail, as can be seen in fig. 2). 



Figure 2. DROID research test aircraft. 
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During the SUAV Auto GCAS project, a pilot with direct line of site was always in control of the 
DROID during takeoff and landing. Once airborne, that pilot normally transferred control to a ground 
control operator (GCO) stationed inside the ground control van. Another aircraft control option was to 
operate the DROID in a manner similar to a remotely piloted vehicle (RPV) from a small cockpit inside the 
ground control van. A safety pilot using a handheld radio controller (fig. 3) had the responsibility of taking 
control if the Auto GCAS algorithms initiated unwarranted maneuvers. 

On a few test missions during which the avoidance maneuvers were accomplished close to the ground 
control van, takeoff and landing was accomplished by the safety pilot. However, on most test missions the 
avoidance maneuvers were accomplished well away from the ground control van, so the safety pilot 
(with the handheld radio controller) needed to be much closer to the test location. In those situations another 
takeoff and landing pilot used a separate handheld controller that was wired directly to the ground station 
inside the ground control van. Once airborne, the takeoff and landing pilot typically transferred control to 
the GCO, who controlled the aircraft using standard DROID control options (mainly waypoints) to put the 
aircraft into holding patterns and set up the test maneuvers. 

All of those control options were processed by the onboard Piccolo II autopilot (Cloud Cap Technology, 
Hood River, Oregon). The Piccolo II autopilot, shown in figure 4, measures 5.6 by 1.8 by 2.4 in and weighs 
7.7 oz. The Piccolo II autopilot was used as an essential component, not just for basic aircraft control, but 
also as the primary source of input data for the Auto GCAS algorithm, the mechanism for responding to 
avoidance maneuver commands, and as a primary instrumentation source for post-flight data analyses. The 
Piccolo II autopilot communicated with a portable ground station located inside the ground control van 
using a 900-MHz, 1 -W data link. 



Figure 3. Safety pilot handheld controller. 


Figure 4. Piccolo II autopilot. 
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Ground Control Van 


The primary mission control for all SUAV Auto GCAS test missions was from the ground control van 
(fig. 5). A safety pilot (or the takeoff and landing pilot) was always ready to take direct control of the 
DROID for any reason, including loss of the communications link from the ground control van. 
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Figure 5. DROID and ground control van. 

The interior of the ground control van included the following standard elements: 

• A COTS portable ground station (fig. 6) provided the necessary link to the onboard Piccolo II 
autopilot through antennas set up on the ground control van. 

• A laptop computer with COTS Piccolo command center (PCC) (Cloud Cap Technology, Hood 
River, Oregon) software installed (fig. 7) enabled the GCO to control the DROID. Control inputs 
were accomplished by a combination of keyboard and mouse commands. 

• A small ground cockpit (fig. 8) provided the option for a research pilot to control the DROID as an 
RPV. The ground cockpit was assembled from a combination of COTS and custom components. 

• Ultra-high frequency (UHF) and very high frequency (VHF) radio (for voice communications). 
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Figure 6. Portable ground station. 


Figure 7. Piccolo command center (installed on 
laptop). 
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Figure 8. Ground cockpit. 

Additional ground control van elements installed in support of the SUAV Auto GCAS project 
included: 

• A laptop computer with Auto GCAS user interface (UI) software installed; and 

• Wind station equipment and laptop display. 
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The ground cockpit is shown in figure 8. The interior setup within the ground control van is shown in 
figures 9 (looking aft) and 10 (looking forward). 
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Figure 9. Ground control van interior (looking aft). 



Figure 10. Ground control van interior (looking forward). 

Physical Components of SUAV Auto GCAS 

A simplified diagram of the essential Auto GCAS components for the smartphone-on-ground 
configuration is shown in figure 1 1(a). The components shown in blue were standard for the DROID and 
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ground control van. Once the DROID was airborne, the GCO normally entered control commands into the 
PCC laptop. Control commands typically directed the DROID to a series of waypoints in a predefined 
pattern. 

The portable ground station provided a two-way command and control link between the PCC laptop 
and the Piccolo II autopilot on board the DROID. 

The components shown in gold in figure 1 1(a) were unique to Auto GCAS. The UI laptop provided 
interaction with the Auto GCAS algorithms hosted on the smartphone. The UI laptop also provided the 
operator with the ability to set up the Auto GCAS mode states and algorithm options, along with displays 
for monitoring Auto GCAS status. The UI laptop implemented Auto GCAS avoidance maneuver 
commands through the portable ground station to the Piccolo II autopilot. The portable ground station 
basically acted as a pure feed-through in both directions. The UI laptop also provided a way to record data 
independent of the smartphone or the on-board Piccolo II autopilot. 


A simplified diagram of the essential Auto GCAS components for the smartphone -on-aircraft 
configuration is shown in figure 1 1(b). 

In addition to the smartphone installed on the DROID, a Gumstix® (Gumstix, Inc., San Jose, California) 
personal computer was needed to provide an interface between the USB connection on the smartphone and 
the RS-232 connection on the Piccolo II autopilot. The UI Auto GCAS avoidance maneuver processing and 
Piccolo UI software were ported to the Gumstix® personal computer, and a messaging interface was added 
to both components. In this configuration, all Auto GCAS avoidance maneuver decisions were made on 
board the DROID without the need for aircraft state data to be received on the ground and avoidance 
maneuver commands to be sent back up to the aircraft. The UI laptop still communicated with the 
smartphone through the portable ground station and Piccolo II autopilot to set up Auto GCAS mode state 
and algorithm options, and also provided the UI operator with displays by which to monitor Auto GCAS 
status. 


On-aircraft components 
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Figure 11(a). Phone-on-ground. 


Figure 11(b). Phone-on-aircraft. 


Figure 1 1 . System diagrams. 
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Software Components of SUAV Auto GCAS 


One of the key concepts for the overall ACAT program was to develop a modular architecture that 
could be applied to a variety of aircraft platforms. The F-16 FRRP Auto GCAS project began that process, 
and the SUAV Auto GCAS project further developed the modularity of each software component. 
A top-level diagram of the SUAV Auto GCAS modular architecture is show in figure 12. 
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Figure 12. Top-level modular architecture. 

A general description of the modular architecture is provided in this paragraph and more detailed 
functionality of each of the blocks is described in the following sections. The “Sense Own-State” module 
provided basic aircraft state information to the “Predict Avoidance Trajectories” module, which calculated 
the three-dimensional flightpaths for each of the three options for an avoidance maneuver (left, straight, 
and right). The “Sense Terrain” module generated a local map of digital terrain data from a much larger 
DEM. That process included decompression of the highly compressed data stored within the DEM. The 
“Identify Collision Threats” module scanned the digital terrain near each of the three trajectory predictions 
and converted the results into two-dimensional terrain profiles. The scanning process included uncertainties 
to account for the fact that the actual avoidance maneuver might not follow the predicted trajectory exactly. 
The “Determine Need to Avoid” module compared the three predicted trajectories with the associated 
two-dimensional terrain profiles. When the last of those three trajectories intersected with its terrain profile, 
an avoidance maneuver in that direction was communicated to the “Avoid” module, which then sent the 
appropriate commands to the autopilot. The “Common Interface” modules represent integrity checks that 
were accomplished at various points in the algorithm. 

Due to the limited budget and shift to using Java™ as the programming language for the SUAV Auto 
GCAS code, the resulting implementation may not be as portable to other platforms as was originally 
intended. The basic functionality shown in figure 12 was implemented, but the code itself may not be as 
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easy to tailor to future applications as desired. The concurrent iGCAS project has developed a manual 
warning system for general aviation use, hosted on a smartphone, and has further matured the modular 
architecture and portability. 

Some of the modules shown in figure 12 are fairly independent of the specific platform; other modules 
must be tailored for the characteristics of the intended platform. However, even the modules that require 
tailoring can use common design techniques and can build on the prior experience of similar platforms 
(fighters, UAVs, helicopters, transports, et cetera). 

The following sections describe each module at a generic level and then more specifically as applied 
on the SIJAV Auto GCAS project. Some of the generic module descriptions also provide an overview of 
techniques used on the F-16 FRRP (ref. 2) to show that Auto GCAS can be successfully implemented using 
varied methods. 

The SUAV-specific modules were generally coded within the smartphone software, but a few elements 
(such as signal conditioning) were coded within the UI software. Future collision avoidance projects may 
choose to implement signal conditioning as part of the “Sense Own-State” module. 

Generic “ Sense Own-State ” Module 

The generic “Sense Own-State” module was a basic part of the modular architecture. Typically, the 
primary sources for these state values were outputs from a GPS/INS and an air data system, as represented 
by figure 13. The main purpose for this module was to provide enough information about the current state 
of the aircraft to support trajectory estimations far enough into the future to be useful for avoiding collisions. 
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Figure 13. “Sense Own-State” module. 

For high-performance aircraft, that extrapolation into the future could comprise several miles but might 
only cover 10 or so seconds. For lower-performance aircraft, that extrapolation could also need to be several 
miles (in order to ensure clearance over tall terrain features) but might cover more than 60 s. Those 
extrapolation techniques are covered in the discussion of the “Predict Avoidance Trajectories” module. 
This section limits discussion of the “Sense Own-State” module to the source data used to accurately locate 
the aircraft prior to the extrapolation. 
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It may be surprising that Auto GCAS does not need a dedicated sensor for altitude above ground level 
(AGL). Auto GCAS algorithms only rely on the GPS/INS altitude relative to a digital terrain map. 
Therefore. Auto GCAS does not require a radar altimeter or laser altimeter. This is a significant advantage 
for military aircraft, which need to minimize emissions that can reveal aircraft position to the enemy. Any 
aircraft needing Auto GCAS can also avoid the extra cost associated with installing a dedicated AGL sensor. 

Since many modern aircraft have access to high-quality position information, this module was much 
less of a challenge than it had been in past decades. Embedded GPS/INS (EGI) capability has become 
standard on fighters and UAVs and is even becoming common on general aviation aircraft. 

The primary GPS/INS outputs of latitude, longitude, and altitude are essential for any type of collision 
avoidance system. The accuracy of those outputs has evolved such that navigation uncertainty is no longer 
a significant impediment to collision avoidance systems. 

Uncertainties in latitude and longitude can now be encompassed by horizontal errors of 50 ft or less. 
However, the remaining navigation uncertainty is still accounted for, as discussed in the “Generic ‘Identify 
Collision Threats’ Module” section below. 

The vertical accuracy of many GPS/INS altitude outputs has also improved dramatically. Wide Area 
Augmentation System (WAAS) GPS/INS units can provide vertical accuracies within 40 ft. However, 
global positioning system/ inertial navigation system units can output altitude values in more than one 
reference frame. The most common are mean sea level (MSL) and World Geodetic System - 1984 
(WGS84). For example, the F-16 used an MSL-based reference frame, whereas the Piccolo II autopilot on 
the SUAV Auto GCAS project used a WGS84 reference frame. Either altitude reference frame can work 
for collision avoidance systems, but care must be taken to ensure that ah modules use the same reference 
frame. A factor for the vertical accuracy of the GPS/INS contributed to the generalized “built-in” buffer as 
discussed in the section “Generic ‘Determine Need to Avoid’ Module,” below. 

Any production implementation of Auto GCAS on a low -performance aircraft (such as a UAV or many 
general aviation aircraft) will probably require some sort of density altitude state to use as an input to the 
trajectory prediction. The impact of non-standard day performance on the trajectory prediction could be 
very significant, particularly for operations near the service ceiling. In practice, a sensor for outside air 
temperature (OAT) may be sufficient, but each low -performance aircraft may have unique requirements. 

Global positioning system / inertial navigation system units normally provide additional aircraft state 
information that is useful for collision avoidance systems. Euler angles, angular rates, and linear 
accelerations may ah be important inputs to a collision avoidance system, depending on the platform. More 
of those terms would be needed for a high-performance aircraft such as a fighter; fewer terms may be 
sufficient for a lower-performance aircraft such as a UAV or transport. 

Air data systems are another fundamental source of aircraft state information that might be needed as 
input data for collision avoidance systems. Some form of airspeed is probably important because it directly 
affects the maneuvering capability of any platform. The overall pitch and roll authority of a given platform 
will be a function of airspeed, as will the initial dynamic response to an avoidance maneuver command. 
Other air data terms such as angle of attack and sideslip may also be candidates for inputs to a collision 
avoidance system for some platforms, especially if improved-accuracy wind estimates are needed. 

Many current-generation GPS/INS systems also provide a wind estimate by comparing inertial and air 
data sources. The need for wind as an input to a collision avoidance system will depend on the platform. 
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High-speed aircraft (such as fighters or commercial transports) may not need a wind estimate. Low-speed 
aircraft such as UAVs or general aviation aircraft may have a more significant need for a wind estimate. 

As a rule of thumb, if the expected winds that may be encountered are less than 15 percent of the slowest 
airspeed for a given platform, wind estimates will probably not be needed and the remaining wind effects 
can be accounted for as part of other uncertainties. If the expected winds that may be encountered are greater 
than 30 percent of the slowest airspeed, it is likely that some sort of wind estimate will be needed. Those 
rule-of-thumb numbers are based on the F-16, which did not need wind estimates, and the SUAV, which 
could have benefited from improved wind estimates. Any wind expectations between 15 percent and 
30 percent of the slowest airspeed on a given platform would need to be more thoroughly evaluated to 
determine whether or not a wind estimate is appropriate. 

The preceding discussion of wind estimates only applies at the state of the aircraft leading up to 
avoidance maneuver initiation. Any wind changes that occur between the initiation of an avoidance 
maneuver and the termination of that maneuver will be more difficult to properly address. Most wind 
estimates depend on the aircraft being in relatively stable flight, and the accuracy of those estimates tends 
to degrade during maneuvering. Most wind estimates assume zero sideslip, but some sort of sideslip state 
sensor may help improve wind calculations. Wind shear as a function of altitude or horizontal position 
could have a significant impact on the repeatability of the overall collision avoidance algorithm. 

Optimizing the use of wind estimates for collision avoidance systems is a significant technical area that 
still needs to be developed. The SUAV Auto GCAS project began that development, but more work is 
needed. Additional discussion of the SUAV experience with winds is described throughout this report. 

Recommendation 1 (Rl): Future Auto GCAS projects should consider applying resources to 
develop improved integration of in-flight wind estimates with the Auto GCAS algorithm. 

Regardless of the input source being used, consideration should be given to what type of signal 
conditioning needs to be applied. The noise level inherent to individual parameters can dictate how much 
smoothing (if any) is needed. The most important outputs of a GPS/INS (latitude, longitude, and altitude) 
have most likely gone through a Kalman filter of some type, so a certain amount of smoothing can be 
expected in those source parameters. Other outputs, such as longitudinal acceleration and roll rate, may 
have high residual noise levels and an appropriately -designed smoothing algorithm may be warranted. The 
“SUAV Auto GCAS ‘Common Interface’ Module” section below contains additional discussion of signal 
conditioning as applied on the SUAV project. 

A related consideration is the sample rate for each source of state data. Clearly, the sample rate needs 
to be fast enough to allow the ensuing trajectory predictions to keep up with ongoing aircraft motions. 
High-performance (or high-speed) aircraft will require a higher sample rate than low-performance / 
low-speed aircraft. If the computational capability of the intended platform is limited enough to force a low 
sample rate, the collision avoidance algorithm can compensate for that by increasing the time-delay phase 
of the trajectory prediction (discussed further in the “Predict Avoidance Trajectories ” module sections 
below). However, there is a limit, and at some point that extra time delay could contribute to early avoidance 
maneuver activations and could be considered a nuisance. This is one of the motivations for a 
clearly-defined nuisance criterion on any collision avoidance project (as discussed in the “Available 
Reaction Time ” section below). 
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SUAV Auto GCAS “Sense Own- State” Module 


This section provides some insight into the choices that were made for the input parameters that fed the 
SUAV Auto GCAS algorithm. A summary of the fundamental input parameters follows: 


Parameter 

• Latitude 

• Longitude 

• Altitude (WGS84) 

• Calibrated airspeed 

• Bank angle 

• Dive angle (derived) 


Source 

Piccolo 11 GPS/1NS 
Piccolo 11 GPS/1NS 
Piccolo 11 GPS/1NS 
Piccolo 11 air data system 
Piccolo 11 GPS/1NS 

Piccolo 11 GPS/INS (based on climb rate and an estimate for true 
airspeed) 


• True heading 

Piccolo 11 GPS/INS 

A summary of the secondary input parameters follows: 

Parameter 

Source 

• Load factor 

Piccolo II GPS/INS 

• Roll rate 

Piccolo II GPS/INS 

• Wind speed (derived) 

Piccolo II GPS/INS/air data 

• Wind bearing (derived) 

Piccolo II GPS/INS/air data 


The fundamental input parameters were essential to proper operation of the SUAV Auto GCAS 
algorithm. The secondary input parameters were implemented in order to assess their importance and to 
evaluate the need for those parameters in similar applications. 

None of the fundamental input parameters required special signal conditioning. Those parameters were 
adequate as they were output from the Piccolo 11 GPS/INS or air data system. During the early SUAV Auto 
GCAS design process it was decided that the only input parameters that required signal conditioning were 
the secondary input parameters roll rate and the wind values. The “SUAV Auto GCAS ‘Common Interface’ 
Module” section below contains additional discussion of signal conditioning for those parameters. 

Generic “Sense Terrain ” Module 

Although this module was implemented as part of the SUAV Auto GCAS project, the resulting methods 
have much broader applications to any Auto GCAS project. In particular, very efficient techniques have 
been developed to utilize DEM at the core of this module. As represented in figure 14, the basic components 
of this module include DEM that cover a large enough region to support mission requirements, and a map 
handler to convert the very large regional map into local maps for the immediate area around the aircraft. 
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Figure 14. “Sense Terrain” module. 

An overall guiding principle was to provide a wide variety of users with the “best available” DEM for 
input to the Auto GCAS algorithms. In this context, “best available” meant high resolution and accuracy as 
well as the DEM source being widely accessible (lacking the classification restrictions of some military 
sources or the cost implications of some private sources). 

After considerable study it was determined that the best widely-accessible DEM source for Auto GCAS 
applications was the NED produced by the United States Geological Survey (USGS). The NED provides 
horizontal resolutions of 1/3 arc-s (32 ft or better), and has an advertised vertical accuracy of 8 ft root mean 
square error (RMSE). The NED-based DEM are only available for the contiguous United States (CONUS) 
and parts of Alaska. 

The second-best widely-accessible DEM source for Auto GCAS applications was the database resulting 
from the Shuttle Radar Topography Mission (SRTM), produced by the National Geospatial-Intelligence 
Agency (NGA) and NASA. The publicly available SRTM database provides horizontal resolutions of 
1 arc-s (98 ft) for the United States and 3 arc-s over most of the Earth’s landmass. This SRTM database has 
an advertised vertical accuracy of less than 32 ft for most areas within coverage. The SRTM database covers 
approximately 80 percent of the land mass of the Earth (between 60 deg north latitude and 56 deg south 
latitude). The NGA publishes the SRTM database in the standard Digital Terrain Elevation Data (DTED) 
format, which is a format different than that of the NED. 

Several additional DEM sources provide coverage of the remaining areas of the Earth, but often at 
lower resolutions and degraded vertical accuracy. One of those sources has been labeled “Legacy” DTED 
to distinguish from SRTM DTED. Legacy DTED is also available from the NGA and has been a common 
source for terrain data prior to SRTM. Although Legacy DTED was a useful source in its time, it contains 
many discontinuities across longitudinal-latitudinal boundaries and localized artifacts that can result in 
vertical errors of hundreds of feet (in some cases there exists over a thousand feet of vertical error). 
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The goal of the SUAV Auto GCAS “Sense Terrain” module was to combine the best DEM sources for 
a given area into a single contiguous dataset for the entire Earth. Therefore, the NED was used for the 
CONUS, the SRTM database was used for most of the remaining land mass of the Earth, and other sources 
were used for landmasses not covered by the NED or SRTM. 

A related goal was to demonstrate advanced DEM compression and re -rasterization concepts in a 
practical flight -test environment. Part of that goal included demonstrating how the levels of DEM accuracy 
could be customized in different areas based on the mission needs of the aircraft. 

As an example, an air-superiority fighter mission does not require extensive operations at low altitudes. 
Therefore an Auto GCAS could be developed without the need for high-accuracy DEM over most of the 
surface of the Earth, over which the aircraft would primarily be in transit at high altitudes. However, to 
avoid nuisance Auto GCAS activations, a higher level of DEM accuracy would still be required for the 
terrain within the airspace around typical operating bases. 

It was also recognized that Auto GCAS would become much more practical for many platforms by 
completely avoiding the need to load a specific regional DEM for each mission. In order to achieve all of 
the goals listed above, NASA developed numerical techniques to generate Compressed Digital Terrain 
Maps (CDTM) while maintaining minimal loss of accuracy. 

The generic example CDTM installed for SUAV Auto GCAS flight-testing achieved a compression 
ratio of approximately 2500 to 1 . That level of compression enabled DEM for the entire Earth to be reduced 
in size from 400 GB to 170 MB. This was primarily accomplished using a combination of two numerical 
methods that were well-suited to compress large amounts of terrain elevation data. These two methods were 
known as “tip-tilt” and “semi-regular tree networks.” 

The combined mathematical methods nested a tip-tilted facet (sloped tile) fitting method within a 
recursive subdividing algorithm. The method began with a single very large facet of 1 deg x 1 deg 
(60 nm x 60 nm at the Equator) and used linear regression to fit the sloped tile to the terrain data underneath 
it. If the specified worst-case vertical or horizontal accuracy were exceeded, that facet was subdivided. The 
overarching recursive process continued subdividing the area until the maximum error between all of the 
facets and terrain data underneath them satisfied the targeted error tolerance over the entire cell. With this 
approach, a large global regular network of 1 deg x 1 deg cells (divided along major latitudes and 
longitudes) was produced as a database, where each 1 deg x 1 deg cell contained a semi-regular network of 
free-edged tip-tilted facets of varying size covering the entire cell. 

An example of the tip-tilt concept is shown in figure 15. The enormous advantage of the tip-tilt 
technique is that it more closely matches natural terrain, as opposed to typical DEM flat, rectangular 
polygons arranged in a fixed grid (fig. 16). As can be seen, the tip-tilt facets tend to have errors at the 
corners. These corner errors can appear large compared to neighboring facets, but they are actually much 
smaller overall than similar errors that are induced along the edges of the flat rectangular DEM polygons. 
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Figure 15. Example of tip-tilt concept. Figure 16. Example of typical DEM data. 

The semi-regular tree compression technique allowed CDTM to be generated using facets that did not 
need to be arranged in a consistent “n x n” grid. Therefore, a single facet could represent many square miles 
over the Great Plains of the central USA. Many more facets were needed to cover the Rocky Mountains, 
but the sloped facets still fit those natural features much better than did flat rectangular polygons. The result 
was a dataset that was much smaller in size than would otherwise have been obtainable. 

The main product of the NASA CDTM development effort was a very flexible software package that 
can customize a CDTM to meet the requirements of any Auto GCAS project. That product is called the 
Global Elevation Data Adaptive Compression System (GEDACS). NASA is in the process of applying for 
a patent for the GEDACS process (ref. 12) and the software will be available for public use via NASA 
license. Figure 17 shows an example GEDACS output representing the combined application of the tip-tilt 
technique and the use of semi-regular tree networks. 



Figure 17. Example of GEDACS CDTM product. 
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The GEDACS was also designed to provide improved vertical accuracy in particular areas where a 
given platform requires low-altitude operations, such as near airfields or along low-altitude training routes. 
The GEDACS provides plenty of flexibility to meet the individual requirements of a given platform while 
minimizing storage space. 

In the case of the generic example of worldwide CDTM used for SUAV Auto GCAS, the worst case 
for either vertical or horizontal accuracy was specified to be 500 ft anywhere on the Earth. A vertical 
accuracy of 500 ft would probably provide adequate Auto GCAS functionality for an aircraft that does not 
need to spend much time at low altitudes other than for takeoff and landing. Therefore, the SUAV Auto 
GCAS CDTM with worldwide coverage could be applicable to high-altitude platforms including many 
UAVs, airline transports, and even fighter aircraft that do not have a requirement for low-altitude strike 
missions. 

Once the generic example of worldwide CDTM had been generated, the SUAV aircraft was used as a 
testbed to demonstrate that this CDTM data could be accessed and used in a real-time flight-test 
environment. A key part of that demonstration included the ability to re-rasterize the CDTM in real time so 
it could be accessed by Auto GCAS using a typical rectangular grid in the local area around the aircraft. 
That re-rasterization logic was not a trivial design effort. It required interpretation of data that could 
represent many square miles or a few hundred square feet, followed by conversion of those data into a 
rectangular grid. 

Since any aircraft equipped with Auto GCAS will constantly be moving from one DEM area to another, 
a map handler was developed. The map handler was designed to add new local maps as the aircraft moves 
forward, and to remove local maps covering areas behind the aircraft (as those maps are no longer needed). 

SUAV Auto GCAS “Sense Terrain” Module 

In addition to the generic example of worldwide CDTM, local areas were also customized for SUAV 
flight-test operations. These higher-accuracy portions of the CDTM encompassed most of the Edwards Air 
Force Base (EAFB) restricted area, including much of the extreme terrain in the southern Sierra Mountains, 
and were considered nearly “lossless” compared to the NED source data. The large EAFB restricted area 
also included the three SUAV test areas: the northern part of Rosamond Lakebed, the North Base runway 
area at EAFB, and the GCAS Valley (near Fremont Peak). Only the GCAS Valley test area is discussed in 
detail in this report. The other two test areas were primarily used for functional checkout flights and 
preliminary flight tests. 

The EAFB restricted area map was generated by GEDACS using a worst-case allowable threshold of 
20 ft. That small error value resulted in GEDACS selecting the minimum facet size throughout the 
restricted area (the minimum facet size had been specified as approximately 3.5 arc-s on each side). Using 
these techniques helped maintain the CDTM vertical accuracy in the flight-test areas at approximately 
10 ft or better compared to the NED source data. 

In order to obtain an independent source for the key terrain features in the GCAS Valley area, 
representatives from NGA stationed at EAFB were requested to conduct a ground survey. The results of 
that survey are discussed and compared with the customized CDTM data in the “Ground Survey at GCAS 
Valley Test Site” section of this report, below. 

Generic “Common Interface ” Module 

The primary function of the generic “Common Interface” module (fig. 18) was to communicate all of 
the input parameters needed by the Auto GCAS algorithm. This module also acted like an “input voting 
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plane.” The intent was to accomplish integrity management checks on the incoming data to ensure that 
appropriate values were fed to the Auto GCAS algorithms. However, those inputs were typically only 
single-string, so there were no redundant inputs to compare and voting logic could not be applied. 
Therefore, the main goal was to ensure that the incoming data were not stale or otherwise corrupted. 



Determine need to avoid 


Identify collision threats | compare trajectories 
to simplified terrain 


Scan and simplify terrain profile 
including trajectory uncertainties 


Common 

interface 


150056 


Figure 18. “Common Interface” module. 

One of the general techniques used was heartbeat checks. Heartbeat checks have been typically applied 
between hardware components. The sending component includes a heartbeat signal as part of its output data 
structure, and the receiving component checks to confirm that the heartbeat changes in the expected way. 
If the received heartbeat does not change, a FAIL state is set to inhibit Auto GCAS avoidance maneuvers. 

Another type of check used was called a “reasonableness check,” and was used to ensure the incoming 
data were within a reasonable range of values. For example, altitude inputs can be checked for values that 
are considered excessively high or excessively low for the expected operations of an aircraft. If an altitude 
input for an SUAV had a value of 50,000 ft, those data most likely would be corrupt and should not be used 
in the avoidance maneuver decision logic. 

Care must be taken to not over -design reasonableness checks. It is very easy for designers to come up 
with a wide range of creative checks that may not function as intended with real-world data. Noisy input 
data can be particularly troublesome if reasonableness checks are applied that use differentiation and 
therefore amplify the noise. Noise amplification can lead to inappropriately setting FAIL states and inhibit 
avoidance maneuvers when there is nothing that is actually wrong with the input data stream. 

It is also advisable to incorporate integrity management checks that are self-recovering. If the 
conditions that induced an invalid check are no longer true, the FAIL state should be removed automatically 
and allow Auto GCAS avoidance maneuvers to resume as needed. 

The F- 16 Auto GCAS implementation also used a number of interlocks. Interlocks prevented avoidance 
maneuver commands from being initiated when outside of the intended design envelope (that is, too slow, 
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gear down, aerial refueling door open, excessive uncertainty in the navigation system accuracy, excessive 
angle of attack, relevant failure modes, et cetera). 

Developmental flight-test experience with the F-16 Auto GCAS has indicated the need for another 
monitor to check for corrupted digital terrain data. Although several methods might be used to accomplish 
this check, the goal would be to ensure that the DEM loaded into the aircraft has not been corrupted on the 
data cartridge since the time it was downloaded from the original source data (that is, via a mission planning 
process). The F-16 Auto GCAS designers implemented a checksum for groups of digital terrain data within 
the overall dataset. If the expected checksum for a given group did not match the checksum from the source 
data, Auto GCAS avoidance maneuvers were inhibited. After implementation, this method worked very 
well to isolate and protect against nuisance activations in areas with corrupted terrain data. 

Recommendation 2 (R2): Future Auto GCAS projects should consider implementing a monitor 
to isolate and protect against corrupted digital terrain data. 

Recent experience during operational testing of the F-16 Auto GCAS indicated the need for another 
type of integrity management monitor. The F-16 Auto GCAS implementation depended upon a flyup 
request bit that was communicated from the single-thread avionics system to the quad-redundant flight 
control system. No problems were observed during several hundred flights of developmental testing. 
However, on one sortie during operational testing it was determined that an unusual multiplexer (mux) bus 
contention problem induced by one of the remote terminals on the mux bus could lead to a false flyup 
request bit. 

Recommendation 3 (R3): Future Auto GCAS projects should consider implementing a monitor 
to protect against false requests for avoidance maneuvers. 

Although Recommendations 2 and 3 were primarily based on experience with Auto GCAS as 
implemented on the F-16, similar hypothetical situations could also have occurred with the SUAV 
implementation. The resultant lessons learned will still have important significance for future Auto GCAS 
projects. 

SUAV Auto GCAS “Common Interface” Module 

The SUAV Auto GCAS implemented integrity management checks in several different ways. These 
methods were heavily influenced by the hardware configuration (refer to figs. 1 1(a) and 1 1(b)). 

The smartphone hosted all of the Auto GCAS -specific algorithms. The smartphone also hosted a limited 
set of integrity management checks that were only applied to incoming data from the UI (either the laptop 
computer or the Gumstix® personal computer). After initial power-up, the smartphone was ready and 
waiting for incoming data from the UI. The actions taken by the smartphone depended upon the mode state, 
as discussed in the “SUAV Mode States” section below. 

The UI hosted the integrity management checks. When the smartphone was on the ground, these checks 
were hosted on the UI laptop computer. When the smartphone was on board the aircraft, these checks were 
hosted on the Gumstix® personal computer. 

Regardless of the location of the smartphone, the UI integrity management checks were applied for 
two sets of incoming data. One set of checks was applied to incoming data from the smartphone. The other 
set of checks was applied to incoming data from the Piccolo II autopilot (as communicated through the 
Piccolo II autopilot ground station when the smartphone was on the ground). 
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The three basic types of SUAV Auto GCAS integrity management checks were: 

• Signal conditioning, 

• Exception handling, and 

• Connectivity and throughput checks. 

Each type of integrity management check is discussed in the following sections. 

Signal Conditioning 

Preliminary flight-test data indicated that the noise levels of the Piccolo-II-autopilot-calculated winds 
and sensed roll rate could skew the performance of the Auto GCAS algorithm if not smoothed. Therefore, 
an attempt was made to apply moving averages to the relevant outputs from the Piccolo 11 autopilot. 

Those moving averages were applied within the UI software to avoid adding computational load to the 
smartphone software. When the smartphone was on the ground, the UI smoothing was hosted on the UI 
laptop computer. When the smartphone was on board the aircraft, the UI smoothing was hosted on the 
Gumstix® personal computer. 

The implementation of the various smoothing algorithms was considered a low priority during the 
design process for this flight -test demonstration project. The end result was that a moving average was not 
applied to the wind values as input to the Auto GCAS algorithm, only to some of the wind parameters 
available in the post-flight data. Therefore, the Auto GCAS avoidance maneuver decisions were made 
solely on the instantaneous wind values provided as output from the Piccolo II autopilot. 

A moving average smoothing algorithm was implemented on the roll rate input as intended. An error 
was found in the roll rate averaging affecting the data that were used to derive algorithm parameters. 
The software problem was corrected; however, given a lack of funding and time to re-evaluate and correct 
the affected algorithm coefficients, the decision was made to simply zero out the roll rate input to the 
Auto GCAS algorithm because of its status as a secondary parameter. 

Based on early flight -test results it was decided that the load factor output from the Piccolo II autopilot 
did not require smoothing. The load factor noise was typically associated with engine vibration and was at 
a high enough frequency not to interfere with the Auto GCAS. However, later flights were conducted in a 
more turbulent environment, in which the load factor variations due to turbulence could easily exceed 
+/-0.5 g. Because the maximum Auto GCAS command capability was established to emulate a 
medium-to-large UAV with a 40-deg bank angle limit, the maximum sustained load factor was 
approximately 1.3 g. That limit placed the entire normal maneuvering envelope of the test aircraft roughly 
between 1.0 and 1.3 g, which was overshadowed by the turbulence response of +/-0.5 g or greater. 

Because the Auto GCAS avoidance maneuver decisions were made solely on the instantaneous load 
factor values output from the Piccolo II autopilot, the timing of the initiation was particularly susceptible 
to turbulence effects. In hindsight, it would have been better to also include a smoothing algorithm for the 
load factor before it was input to the Auto GCAS algorithm in order to minimize the potential for 
inappropriate activations due to turbulence. Another option would have been to remove the load factor as 
an input to Auto GCAS because of the poor signal-to-noise ratio. 

The various ways to implement and optimize Auto GCAS-related smoothing algorithms is one of the 
remaining technical issues that warrant additional research to provide future projects with a more solid 
foundation. Each platform will undoubtedly require some unique smoothing concepts, but there may also 
be generic smoothing concepts that could apply across multiple parameters on multiple platforms. 


27 



Recommendation 4 (R4): Future Auto GCAS projects should pay special attention to the input 
signal conditioning necessary for that particular implementation. 

Exception Handling 

The primary purpose for exception handling checks was to identify suspect data and automatically 
adjust those data as needed to avoid negative impacts to the Auto GCAS algorithm. Several types of 
exception handling checks were hosted in the UI software, including: 

• Divide -by-zero checks; 

• Valid-range checks; and 

• Off-map checks. 

In general, if these checks identified suspect data, the result led to a FAIL state. These exception 
handling checks functioned adequately with no negative impact to the flight-testing process. 

Connectivity and Throughput Checks 

The primary purpose for connectivity and throughput checks was to confirm that the communication 
between components was proceeding as required. These checks were hosted in the UI software and in the 
smartphone software. In general, if the continuity and throughput checks determined that communication 
was not proceeding as required, the result led to a FAIL state. Examples of connectivity and throughput 
checks included: 

• Stale data checks, and 

• Packet counting checks. 

These checks led to FAIL states on a number of flight tests. The checks correctly identified 
communication problems between components, but the ensuing action taken after setting the FAIL state 
evolved over time. Additional discussion is provided in the “SUAV Mode States” section below. 

The connectivity check “timeout value” was changed as a result of flight-testing. The original timeout 
value was selected to be 0.5 s to ensure that the FAIL state would be entered before the aircraft had traveled 
far enough to miss an entire re -rasterized terrain tile (a 3-arc-s rectangle). When flight-test telemetry 
dropouts were inducing excessive FAIL states, the timeout value was increased from 0.5 s to 5.0 s to provide 
an opportunity for the telemetry to improve before aborting a flight-test run. The 5-s timeout value was 
acceptable in flight-testing because a safety pilot was always in position to take control. A timeout of 5 s 
would probably be too large for a production implementation of Auto GCAS. 

Generic “Predict Avoidance Trajectories ” Module 

This module requires the greatest amount of customization for the dynamic response of each specific 
platform. However, that customization does not require as much effort as might be expected. Figure 19 
shows the overall concept for this module. The solid blue line within the “Predict Avoidance Trajectories” 
module on figure 19 represents the predicted trajectory if an avoidance maneuver were initiated at that 
instant (that is, the blue line represents Altitude versus Range from the initiation point). 
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Figure 19. “Predict Avoidance Trajectories” module. 

The first basic decision that must be made for every new Auto GCAS design is to define the specific 
avoidance maneuvers that will be implemented. The selected avoidance maneuvers must be appropriate to 
the type of mission that the platform conducts and will be directly influenced by the maneuvering capability 
of the aircraft. 

An important Auto GCAS design philosophy is to choose avoidance maneuvers that are as aggressive 
as a pilot would be in a situation that requires immediate action to avoid hitting the ground. Therefore, Auto 
GCAS avoidance maneuvers should utilize a large portion of the maneuvering capability that is available 
at a given set of flight conditions. Avoidance maneuvers that do not utilize a large portion of the 
maneuvering capability could lead to nuisance activations. However, avoidance maneuvers that might 
exceed aircraft structural limits or cause the aircraft to run out of airspeed before the avoidance maneuver 
is complete should not be used unless given careful consideration. 

A common design philosophy that was discussed early in the design process on several Auto GCAS 
projects can be paraphrased as, “It’s acceptable to exceed structural limits during an Auto GCAS avoidance 
maneuver if that helps an aircraft avoid impact with the ground.” However, any avoidance maneuver 
designed using that philosophy could not be flight-tested without risk of exceeding those structural limits. 
Great care would be needed to avoid conditions that might lead to an over-g; despite the best efforts of the 
test team, an over-g might still occur unless those boundaries are very well-defined and the aircraft response 
is especially predictable and controllable. 

Another common design philosophy that was discussed on several Auto GCAS projects but has not yet 
been implemented successfully can be paraphrased as, “Even if an aircraft might run out of airspeed during 
an Auto GCAS avoidance maneuver, go ahead and let it try, since that would be better than hitting the 
ground.” That design philosophy might work reasonably well at some conditions, but the ability to generate 
useful trajectory predictions becomes less reliable at the high angle of attack associated with low airspeed 
maneuvering. The overall result of trajectory prediction uncertainty could lead to excessive nuisance 
activations. The design team on each Auto GCAS platform will need to decide, “How slow is too slow?” 
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In the case of the high-performance F-16, a single basic flyup maneuver was used. As described earlier, 
a simplified description of the F-16 flyup maneuver was “roll toward wings-level and pull at 5 g until clear 
of terrain.” That simple description covers the essential F-16 flyup maneuver although there were several 
important modifications dependent on steep dives, high roll rates, et cetera. The F-16 typically had enough 
kinetic energy to convert into potential energy to allow successful flyup maneuvers straight over all but the 
tallest terrain features. 

In the case of a relatively low-performance aircraft like the DROID (or, rather, the medium-to-large 
UAV it was constrained to emulate), it was not practical to expect successful avoidance maneuvers directly 
over typical terrain features. In particular, given the very limited sustained climb performance of 
medium-to-large UAVs (not much more than 1000 fpm), avoidance maneuvers that needed to fly over 
large hills or mountains would need to be initiated many thousands of feet prior to that feature. Those 
“straight” avoidance maneuvers would be considered an extreme nuisance by the pilot of a 
medium-to-large-UAV who intended to turn away from a terrain feature long before reaching it. Therefore 
it was necessary to include trajectory predictions for turning maneuvers to either side. 

Recommendation 5 (R5): Future Auto GCAS projects should consider incorporating multiple 
trajectory predictions to provide more than one option and to reduce nuisance potential. 

A full six-degrees-of-freedom simulation is not required to model the trajectory predictions for this 
module. High-fidelity aerodynamic, thrust, and flight control models are not required, although a simulation 
using those models can provide a very helpful starting point if available. If a high-fidelity simulation is not 
available, the necessary parameters can be determined directly from a few simple flight tests. 

For the puipose of Auto GCAS, it is only necessary to model the particular response that is expected 
during an avoidance maneuver. Since the avoidance maneuver itself is usually very simple, the 
corresponding models needed in order to predict the avoidance maneuver trajectory can also be very simple, 
as sketched in figure 20. 



Figure 20. Simple kinematic state model. 
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This methodology models the magnitude and orientation of the lift vector during the avoidance 
maneuver. The magnitude of the lift vector can be modeled by approximating the change in either the 
load factor or the climb rate from the initial state during the transition (the capture phase) to a steady-state 
target, and can continue into the steady-state phase as needed. Similarly, the orientation of the lift vector 
can be modeled based on the initial bank angle and flightpath angle; the change in that orientation can be 
approximated during the transition to the target attitudes, and the resulting orientation can continue into the 
steady-state phase. 

As an example, a fundamental portion of most Auto GCAS avoidance maneuvers is a bank angle 
capture. Given the initial bank angle of the aircraft, a lag/delay phase is used to account for any length of 
time in which no significant change in bank angle occurs (as observed on simulated or flight-test avoidance 
maneuvers). The lag/delay phase can account for the basic dynamics of the overall system and can also be 
used to add a term to account for Auto GCAS implementations that need to use a lower frame rate. As an 
example, the SUAV roll rate lag term was 0.2 s as determined by inspecting flight-test time histories from 
early characterization flights. Using data from the same SUAV characterization flights, the airspeed lag 
term was selected to be 0.24 s and the vertical velocity lag term 0.3 s. 

A simple roll rate onset term can be used during the capture phase, until the bank angle approaches the 
tai'gct value. Individual aircraft dynamics may result in overshoots of the target bank angle, but, if small 
enough, that overshoot may not need to be modeled as part of the trajectory prediction. As the target bank 
angle is being approached, the roll rate model is attenuated and bank angle is maintained during the 
steady-state phase until the end of the avoidance maneuver. The bank angle lag/delay term and the roll rate 
onset term may need to be scheduled as a function of flight conditions. It is unlikely that those terms would 
remain constant across a wide airspeed range. 

Similar simple kinematic models can be used for the other axes that represent an avoidance maneuver. 
A higher-performance aircraft (such as the F-16) may use load factor lag/delay and g-onset as pitch axis 
terms. A lower-performance aircraft, such as a UAV, may use climb rate instead of load factor. An aircraft 
with an auto-throttle may also use thrust command or airspeed command as part of the simple kinematic 
model. Without an auto-throttle, it is likely that airspeed changes during the avoidance maneuver would 
need to be modeled. 

Each axis of the kinematic model is combined into simplified equations of motion to assemble the 
overall trajectory prediction that will be used in the modules that follow. A more detailed description of the 
overall process is contained in reference 9. 

Given the simple nature of the kinematic model, it can be easily tuned as conditions are observed that 
don’t match the original model. Excessively complicated trajectory prediction models can actually be 
harder to tune, take a lot of processor power, and may not provide much improvement in performance. 
“Keeping it simple” is a worthy trajectory prediction goal for any Auto GCAS project. 

Since no aircraft model is perfect, the trajectory prediction should try to account for any uncertainties 
that may not match the modeled trajectory. Those uncertainties can be due to un-modeled effects of gross 
weight, off-standard day performance, local winds, et cetera. However, those uncertainties are usually 
secondary or tertiary effects that can be captured with a few extra simple terms that encompass the 
worst-case effects, and should not require complicated additions to the model. Compensation for these 
uncertainties can be modeled either by specific terms or generalized terms. 

An example of a specific uncertainty term is the use of on-board local wind calculations to capture the 
expected variation due to the magnitude of the headwind, tailwind, or crosswind. Naturally, the ability to 
account for local winds is only as good as the quality of the onboard calculation. An alternative is to assume 


31 



a worst-case magnitude and direction, and include a single term to capture that effect as part of the trajectory 
prediction. That worst-case assumption could be set up differently for left or right trajectory predictions 
(that is, cross winds from opposite sides). 

Generalized uncertainty terms can also capture the overall range of uncertainty for a given platform. 
Monte Carlo simulations are one way to define that overall range of uncertainty. Another way is to use the 
variations observed across a number of flight-test avoidance maneuvers. Those generalized prediction 
variations can be applied as a horizontal uncertainty, a vertical uncertainty, or both. These generalized 
variations can be represented by a standard deviation and can be either positive or negative, so it is 
recommended to account for those variations as part of a root-sum-square implementation in the 
“Determine Need to Avoid” module, as discussed in the section “Generic ‘Determine Need to Avoid’ 
Module,” below. 

The F-16 Auto GCAS implementation did not include an auto-throttle, so most trajectory predictions 
were based on the assumption that the throttle was not moved. Some F-16 trajectory predictions for flyups 
that were initiated at low airspeeds were based on the assumption that the pilot was aware of the low-speed 
condition (which was also annunciated on the head-up display), and would increase throttle as needed. 

The F-16 trajectory predictions were developed by Lockheed Martin Aeronautics using high-fidelity 
simulations of the F-16. However, each F-16 Auto GCAS flight test project also verified the accuracy of 
the F-16 trajectory predictions using a flight-test technique that took advantage of the Pilot Activated 
Recovery System (PARS). The F-16 PARS was already part of the overall system design to provide the 
pilot with an option to initiate an automated recovery in spatial disorientation situations (one of the factors 
that has led to CFIT mishaps). 

Since the F-16 PARS maneuver was designed to be identical to an Auto GCAS flyup maneuver, the 
use of PARS as a flight-test technique was also very effective as a quick way to obtain trajectory data. 
The PARS allowed the test aircraft to be established at a wide range of initial flight conditions, and then an 
Auto GCAS flyup maneuver to be initiated without the need to be in close proximity to terrain. Although 
Auto GCAS maneuvers could be initiated farther from terrain by using a flight-test altitude buffer, that test 
technique still required maneuvering the test aircraft into a particular orientation over a specific piece of 
terrain. The PARS maneuvers allowed the same trajectory data to be obtained independent of the location 
relative to terrain and were, therefore, much more efficient. 

SUAV Auto GCAS “Predict Avoidance Trajectories” Module 

In the case of the SUAV project, a low-fidelity simulation was available, but it was clear that it did not 
represent the actual flight characteristics of the DROID. Even if a high-fidelity, high-confidence simulation 
is available, it is recommended that a small number of flight tests be accomplished to obtain data directly 
from a representative set of planned avoidance maneuvers. 

All of the necessary SUAV trajectory prediction parameters were determined from six preliminary 
flights totaling 4.0 flight hours. This was accomplished by executing a small matrix of avoidance maneuvers 
initiated by the user interface operator (UIO) (similar to PARS) to capture the range of variations that would 
be expected during the planned flight-test missions. The SUAV avoidance maneuvers were defined to take 
advantage of the standard capability of the Piccolo II autopilot. The basic autopilot functions used were: 

• Bank angle command, 

• Vertical rate command, and 

• Indicated airspeed command. 
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The SUAV avoidance maneuvers were defined as: 

• Straight: 

Bank to wings-level; 

Capture 1000 fpm climb; and 
Capture 60 KIAS. 

• Left and right turns: 

Bank to 40 deg left or right, 

Capture 800 fpm climb, and 
Capture 60 KIAS. 

The 40-deg bank target and the 1000-fpm climb rate target were selected to represent reasonable values 
for medium-to-large UAVs. The DROID was capable of a much higher bank and climb rate. An 800-fpm 
climb rate target was selected for the left- and right-turning avoidance maneuvers to mimic reduced aircraft 
performance when some of the excess power was used for turning instead of climbing (800 fpm is roughly 
1000 fpm times the cosine of the 40-deg bank used for turning avoidance maneuvers). 

During the preliminary flights, it was observed that avoidance maneuvers tended to achieve a slightly 
lower climb rate than the value commanded by the autopilot. Although this bias could have been explained 
by a number of different factors, it was easy to account for the bias in the trajectory prediction. A simple 
multiplier of 90 percent was incorporated in the trajectory predictions, resulting in 900 fpm instead of 
1000 fpm for the straight prediction, and 720 fpm instead of 800 fpm for the turning predictions. The result 
was that avoidance maneuvers were initiated slightly earlier but better reflected the actual climb 
performance of the aircraft. 

The DROID tended to change from one climb rate to another very quickly. Therefore the dynamic 
“capture” phase (when the aircraft was pulling up at more than 1 g) was over very quickly and the trajectory 
prediction reflected that short dynamic phase followed by a long steady-state phase. In contrast, an F-16 
flyup could remain at 5 g for an extended period (more than 5 s after initiating from a steep dive) and the 
airplane was often clear of terrain before transitioning to a steady-state climb rate. 

Another practical effect was observed on the preliminary characterization flights when PARS-type runs 
were accomplished. Although the autopilot was given a target of 40 deg for turning avoidance maneuvers, 
in practice the actual bank angle of the DROID tended to oscillate somewhat below 40 deg. Therefore, the 
trajectory prediction bank angle was changed to 37 deg to provide a better match with the actual flight -test 
data. 

The 60-KIAS target airspeed was selected to be near the middle of the airspeed range of the DROID 
(45-80 KIAS) and simulated an optimum climb speed. The SUAV implementation had an advantage over 
the F-16 since an auto-throttle was an inherent capability of the Piccolo II autopilot. Adding an auto-throttle 
to the F-16 would have been prohibitive due to the additional cost. 

It is expected that a generic production UAV Auto GCAS implementation would use avoidance 
maneuver definitions similar to those of an SUAV but would also use more optimal values customized for 
the particular platform. For example, some UAV Auto GCAS designers might choose to use a bank angle 
target scheduled as a function of gross weight and airspeed, a higher climb rate target (where available), 
and would probably select a higher target airspeed. 

During the first few test flights for obtaining trajectory prediction data, it became very apparent that the 
DROID P-factor effect was much more significant than had been predicted by the low-fidelity simulation. 
The P-factor affects propeller-driven aircraft and is particularly apparent at lower airspeeds when such an 
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aircraft is climbing under high power. The P-factor effect was especially noticeable with the high-powered 
DROID. The main impact of the P-factor effect was that when the “straight” avoidance maneuver was 
commanded, the DROID didn’t fly straight - it ended up in a wings-level, climbing turn which drifted to 
the left at over 3 deg/s heading rate (at the slower DROID airspeeds of 40-45 KIAS). A graphical 
representation of drift experienced due to P-factor effect is shown in figure 2 1 . 



Figure 21. Heading drift during “straight” avoidance maneuver. 

A similar heading drift was present in turning maneuvers (i.e.; 40-deg left bank avoidance maneuvers 
had a tighter radius than expected, whereas 40-deg right bank avoidance maneuvers had a wider radius than 
expected). The P-factor effect was significant enough that it was included as part of the trajectory prediction. 

One option for accommodating P-factor effect would have been to adjust the autopilot bank target to 
compensate for the heading drift (by using a biased bank angle target opposing the P-factor effect). That 
option would have required significant regression testing in the hardware-in-the-loop (HIL) simulation 
environment at a time when there was insufficient funding for such testing. In addition, it is likely that a 
single bank angle adjustment for the P-factor effect would not have worked well under all conditions. 
Therefore the decision was made to include the heading drift directly as part of the trajectory prediction. 

Part of the goal of using this approach was to demonstrate the way in which specific aircraft 
characteristics such as P-factor effect can be readily incorporated as part of the trajectory prediction design 
process. The guiding philosophy was to model any unusual aspects in the trajectory prediction instead of 
changing the autopilot. 

Figure 22 shows an example of the three trajectory predictions that were used as part of the SUAV 
Auto GCAS algorithm. The example shows that the straight trajectory prediction isn’t actually straight, but 
includes an allowance for the effects of the P-factor. The example also shows that the left trajectory 
prediction has a slightly tighter radius than the right trajectory prediction to account for the P-factor effect. 
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Figure 22. SUAV three -trajectory example. 

Based on data from the preliminary flights, P-factor also impacted the climb rate, depending on the 
direction of the turn (whether the path of the turn was with or against the P-factor effect). The climb rate 
for the left trajectory predictions was reduced by 200 fpm to reflect this effect. The climb rate for right 
trajectory predictions was increased by roughly 200 fpm. 

Additionally, the preliminary flights indicated that the P-factor effect was stronger when the airspeed 
was being increased at the beginning of climbing maneuvers. The P-factor effect was much less significant 
when the airspeed was decelerating or when the target airspeed was almost achieved. Therefore, the P-factor 
effect was modeled to be roughly half as effective when the airspeed had increased to within 5 kn of the 60 
KIAS target. 

As mentioned in previous sections, the SUAV trajectory prediction also used instantaneous winds as 
sensed by the Piccolo II autopilot to adjust the trajectory prediction. Headwinds shortened the trajectory 
prediction in the direction of flight. Crosswinds shortened the upwind side while extending the downwind 
side. Tailwinds extended the trajectory prediction in the direction of flight. 

Another option worth considering on any Auto GCAS project is to assume the worst -case winds as an 
inherent part of the trajectory prediction. This approach completely avoids reliance on real-time wind 
calculations. The simplest method is to always assume a worst-case tailwind when calculating all three 
trajectory predictions. This method can be further modified by also assuming a worst-case crosswind 
component for the left and the right trajectory predictions. The general effect of these methods is to cause 
avoidance maneuvers to be initiated earlier than they would initiate without accommodated wind effect. If 
the nuisance potential of the earlier initiations can be tolerated, this “worst-case wind” approach may be a 
viable option for many platforms. 

Also as mentioned in previous sections, the DROID was susceptible to turbulence. Vertical gusts (either 
from changes in local winds or flying through the up- or downdrafts created by thermals) often resulted in 
load factor variations in excess of +/- 0.5 g. On occasion these gusts resulted in load factor variations well 
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above +/- 1 g, even when the autopilot was simply attempting to hold level flight. The result was that 
approximately half of the accomplished PARS-type runs showed an un-conservative trajectory prediction 
(that is, the actual aircraft trajectory was closer to the ground than was indicated by the prediction). 

In the context of the Auto GCAS trajectory prediction, the influence of vertical gusts was obtained 
indirectly through the measured climb rate. Given the observed effect of vertical gusts on the DROID, a 
negative 200 fpm “bias” was applied to the measured climb rate input to the trajectory predictions, but with 
no change to the overall trajectory. Therefore, a 1000-fpm measured descent rate resulted in an initial 
condition feeding the trajectory prediction that appeared to be from a 1200-fpm descent rate. A 1-g level 
condition resulted in an initial condition that appeared to be a 200-fpm descent rate. Climbing maneuvers 
were also affected by the bias. The bias generally caused avoidance maneuvers to initiate slightly earlier 
and provided a little more pad relative to the ground. 

The SUAV Auto GCAS algorithms did not include trajectory predictions that were influenced by the 
effects of density altitude. On a hot day, or at altitudes well above the typical test band for the DROID, 
density altitude effects could require significant changes in the trajectory prediction. 

Recommendation 6 (R6): Future Auto GCAS projects for performance-limited aircraft may need 
to consider including density altitude as an input to the trajectory prediction. 

Generic “Identify Collision Threats ” Module 

For any Auto GCAS application, the function of this module can be described most simply as “scan the 
digital terrain near the predicted aircraft flightpath.” Figure 23 shows the overall concept of this module. 
The main purpose of presenting F-16 scan pattern concepts is to show that there are options other than the 
methods used on the SUAV in the following section. Although many of the concepts will be similar for any 
aircraft, the specific methods and values chosen can be different depending on the mission type and the 
maneuvering capability of the relevant aircraft. 


Determine need to avoid 


.dentify collision threats | Compare trajectories 
to simplified terrain 



• Integrity check 
■ Execute avoidance 


Figure 23. “Identify Collision Threats” module. 
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The specifics of the SUAV process are described in the “SUAV Auto GCAS ‘Identify Collision 
Threats’ Module” section below. 

In the case of the F-16, the “Identify Collision Threats” module needed to scan only the digital terrain 
underneath a trajectory that would encompass the possible variations during a “roll toward wings-level and 
pull” flyup. Therefore, the F-16 scan region was relatively straight. The F-16 digital terrain scan area needed 
to be wide enough to capture all of the terrain that might be overflown throughout the entire flyup maneuver. 

The F-16 digital terrain scan also needed to start from initial conditions that could be very dynamic, 
such as a 7-g descending turn with bank angle past 90 deg, steep dives, or a turn reversal with a high roll 
rate. Therefore the F-16 scan region needed to encompass the trajectory of any flyup maneuver that was 
initiated from these types of dynamic initial conditions. 

Figure 24 shows the basic variations in scan pattern shape for the F-16. The scan pattern could be fairly 
narrow for straight-and-level flight. The scan pattern became wider in the direction of the turn. The scan 
pattern was more circular in the case of a steep dive, because the resulting flyup could go in any direction 
depending on the specific conditions at flyup initiation. 



Figure 24. Basic F-16 scan pattern shapes. 

The fundamental tradeoff with the F-16 was that a “too-wide” scan pattern could lead to increased 
nuisance potential because the digital terrain that was being scanned wasn’t actually a threat, causing 
unnecessary flyup activations. A “too-narrow” scan pattern could lead to reduced collision protection if 
the flyup maneuver flew over digital terrain that was not scanned. All Auto GCAS projects will need to 
find an optimal solution to that tradeoff. 

The general philosophy behind the F-16 scan width was to ensure that at least two DEM posts were 
captured by the scan at the base of the scan pattern (near the F-16). This approach was necessary because 
the F-16 scan method looked for individual posts, not the rectangular areas surrounding each post. Given a 
DEM post spacing of 3 arc-s (roughly 300 ft between posts), a minimum scan width of greater than 600 ft 
at the base of the scan pattern ensured that at least two DEM posts were captured. Figure 25 shows how the 
base width and half angle both influence the overall shape of the scan pattern. The half angle represented 
how much the scan pattern needed to grow as a function of distance from the initial point. 
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a = half angle 
b = half width 
B = base width 



Figure 25. Basic F-16 scan pattern terms. 

The chosen F-16 philosophy for scan width worked very well for normal F-16 missions above 500 ft 
AGL. However, for more aggressive missions below 500 feet AGL the wider scan widths would have 
resulted in excessive nuisance flyup activations. Therefore the F-16 design utilized a scan width narrower 
than 300 ft for low-level missions in order to reduce nuisance activations but at the expense of decreased 
collision protection. The tradeoff was considered acceptable because pilots flying those types of low-level 
missions were typically very aware of ground proximity and it was not a requirement to provide 100-percent 
collision protection. In those cases it was considered much more important to not interfere with the mission. 

Another factor that determined scan width was the uncertainty in the navigation solution. Since modern 
embedded GPS/1NS components provide excellent navigation accuracy, the uncertainty factor is no longer 
as significant as it was for older navigation systems. However, it is still possible for the GPS/INS location 
to be off by dozens of feet, and that possibility can be accounted for by increasing the width at the base of 
the scan pattern accordingly. 

Another type of uncertainty that must be represented is called the track uncertainty. During an 
avoidance maneuver, the airplane will probably not track along the centerline of the trajectory prediction. 
That uncertainty grows with time out in front of the point at which the avoidance maneuver would need to 
be initiated. This is why the basic F-16 scan patterns shown in figure 24 get wider as a function of distance 
from the current location of the airplane. The normal F-16 scan patterns got wider at a half angle of 3.5 deg 
compared to the base width, as shown in figure 25. 

The magnitude of the track uncertainty can be obtained either from simulation runs or from flight -test 
maneuvers. The goal is to try to cover all track variations that may occur without making the half angle so 
large that it increases the nuisance potential. 

The length of the F-16 scan shapes was set at 18,000 ft. That scan length was primarily driven by the 
worst-case radius of the circular scan that would be needed to recover from a near-vertical supersonic dive. 
The 18,000-ft scan length also accounted for the tallest rising terrain that was likely to be a factor for the 
F-16 when using the non-circular scan shapes. 

Once all of the DEM posts within a scan pattern have been identified, that information must be 
converted into a form that can be compared with the trajectory prediction. A simple method was used on 
both the F-16 and the SUAV to convert the three -dimensional array of DEM posts within the scan pattern 
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into a two-dimensional matrix. At a series of fixed distances from the airplane (called “range bins”) along 
the centerline of the scan pattern, the highest DEM post at that distance is used to generate a simplified 
two-dimensional matrix, as shown in figure 26. 
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Figure 26. Converting F-16 terrain posts into a two-dimensional matrix. 

Man-Made Vertical Obstructions 

Many digital terrain data sources do not include information for man-made vertical obstructions such 
as radio towers and tall buildings. For example, sources such as NED and Legacy DTED provide 
“bare-earth” data without including man-made structures. One exception is SRTM data, which include a 
portion of some structures. The SRTM methodology was based on radar sensors, it included portions of 
natural or man-made objects that were reflected to the radar receiver on the Space Shuttle. The SRTM data 
tended to clip the maximum height off of tall, thin obstructions such as radio towers because each post was 
averaged over a 60- by 60-m area. 

Neither the F-16 nor the SUAV designs included dedicated data for vertical obstructions or 
obstacles as a core part of the Auto GCAS algorithm. Since the F-16 used SRTM, approximately 
50-70 percent of obstacle height was included in the DTED (for any obstacles that were in place in the year 
2000 when the Space Shuttle mission was accomplished). A deliberate decision was made to not include 
obstacles in the F-16 Auto GCAS because very few historical F-16 mishaps involved obstacles. In addition, 
the F-16 already had a separate obstacle warning system. The SUAV Auto GCAS was a low-budget 
research project; the addition of vertical obstructions to the algorithm was considered out of scope. 

Recommendation 7 (R7): The developers on any Auto GCAS project should consider the addition 
of vertical obstructions as part of the algorithm. 

It is recommended that whatever vertical obstruction database is used be kept separate from the digital 
terrain data until just before the combination is converted into the simplified two-dimensional matrix. This 
approach will allow the vertical obstruction data to be updated independent of the terrain data as new 
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buildings and towers are constructed. Future Auto GCAS projects will undoubtedly report their experience 
with vertical obstruction implementations. It is also likely that obstacle sensors will be developed that could 
help supplement a DEM-based Auto GCAS. 

Natural Vertical Obstructions (Trees) 

Most digital terrain sources do not include information on tree height. Flowever, the SRTM database 
does include any portion of tree height that was reflected to the radar receiver and processed into the 
resulting DTED. It is unlikely that SRTM data captured individual trees, but informal tests have been 
conducted showing that, for more thickly forested areas, approximately 30-70 percent of tree height has 
been reflected in SRTM data, depending on the type of tree and the density of the forest. 

In the near future it may be very practical to include a tree height database that can provide a 
representative buffer for thickly forested areas without adding nuisance potential over areas that are known 
to be barren of trees. Until then, generalized tree buffer terms have been used, as discussed in the section 
“Generic ‘Determine Need to Avoid’ Module” below. 

SUAV Auto GCAS “Identify Collision Threats” Module 

The overall SUAV scan concept was very similar to the F-16. The fundamental steps were: 

• Define a scan pattern that encompasses all DEM posts that might be overflown during the 
corresponding avoidance maneuver (while also keeping the scan pattern small enough to minimize 
nuisance potential); 

• Include an allowance for navigation and track uncertainty; 

• Identify the height of all DEM posts in (or near) the scan pattern; and 

• Convert the highest DEM posts into a two-dimensional matrix for later comparison with the 
trajectory prediction. 

The fact that this Auto GCAS application was for an SUAV provided a number of benefits and 
constraints compared to the F-16. The primary benefits provided by the SUAV were a smaller range of 
airspeeds and much less dynamic maneuvering at initial conditions. The primary constraint was due to the 
lower climb performance. As previously discussed, the lower climb performance of the SUAV required the 
use of turning scan patterns in addition to a straight scan pattern. Due to the slower airspeed of the SUAV, 
turns could be accomplished in a much tighter radius than that of the F-16. Therefore, those turning scan 
patterns could be added while scanning far fewer DEM posts than similar turning scan patterns would 
require for an F-16. These factors enabled simpler and less variable SUAV scan patterns than those required 
for the F-16. 

The total length of the SUAV straight scan pattern was defined to be 18,000 ft (the same as that of the 
F-16). The long scan length was selected because of the limited SUAV climb performance, and provided 
an option to climb straight over large, distant terrain obstacles. The 18,000-ft scan length was also used in 
termination logic to determine when an avoidance maneuver was clear of terrain. 

From a practical standpoint, the 18,000-ft scan length would not be needed in most situations because 
the algorithm would almost always choose one of the turning avoidance maneuvers. One hypothetical 
situation that could result in selection of a straight avoidance maneuver would be a ridge crossing at low 
altitude in which elevated terrain existed on both sides of a saddle. Another hypothetical situation in which 
a straight avoidance maneuver might be selected would be in a very narrow “V” canyon within which 
turning would not be an option but where distant, tall terrain features also existed at the end of the canyon. 
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Figure 27 shows a simplified example of a left turning scan pattern for the SUAV. The solid dark blue 
line represents the centerline of the trajectory prediction for a given set of initial conditions. The purple 
lines represent the outer boundary of the scan pattern including the horizontal navigation and track 
uncertainties. The horizontal navigation uncertainty remained at a constant value of 50 ft throughout the 
scan pattern. The purple lines in figure 27 are a simplified representation of the outer boundaries of the scan 
area (as described below). 
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Figure 27. SUAV turning scan pattern example. 

The dashed blue lines in figure 27 represent the horizontal track uncertainty and increase with distance 
from the initial location. The growth angle for the SUAV track uncertainty was defined as 5 deg for the 
straight scan and 10 deg for turning scans. Those angles were determined from analysis of early flight -test 
runs and included an allowance for changing winds after the avoidance maneuver initiation. Basically, the 
scan angles were adjusted to encompass the variations from run to run. The same technique could be applied 
to simulation runs. 

The right turning scan pattern used the same values for horizontal navigation and track uncertainties as 
did the left scan. However, the resulting shape of the right scans was different due to the effect of P-factor 
on the trajectory prediction centerline (as discussed above). 

The total length of the SUAV turning scan patterns was enough to execute an avoidance maneuver 
through at least 225 deg of turn. A turn of at least 225 deg was sufficient to execute a teardrop-shaped 
maneuver that got the aircraft pointing back toward the inbound flightpath. The teardrop shape can be 
visualized by extrapolating linearly backward for the inbound segment and forward for the outbound 
segment. Those lines converge at the cusp of the teardrop shape. The centerline for trajectory predictions 
at higher airspeeds had a wider turn radius, so the actual length of those scan patterns was correspondingly 
longer. 

Once the SUAV Auto GCAS algorithm determined the size and shape of a given scan pattern based on 
initial conditions, the DEM posts near that pattern were scanned to determine the height of each post. That 
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process required the re -rasterization of CDTM data. For the SUAV Auto GCAS project it was decided to 
re -rasterize the CDTM at the same 3 arc-s post spacing that was used by the F-16. That was a somewhat 
arbitrary decision that was made solely to provide a consistent reference for comparison. The CDTM 
re -rasterization logic allows for selection of any post spacing. 

The SUAV project could have re-rasterized the CDTM into more tightly spaced posts to reflect the 
tighter turn radius compared to an F-16. The SUAV project could also have re-rasterized the CDTM into 
less tightly spaced posts than those of the F-16 to demonstrate that lower-resolution data could have been 
used effectively. Lower-resolution data might have been necessary if the overall Auto GCAS algorithm had 
been constrained by the processor speed on the Android™ platform smartphone; that was not the case for 
the SUAV project, but could be the situation encountered by higher-airspeed aircraft that still need the 
option for multi -trajectory avoidance maneuvers. 

Another SUAV design aspect that was different than that of the F-16 was the way in which digital 
terrain data were determined to be within the scan pattern. The F-16 technique only used terrain data when 
individual terrain posts were inside the scan pattern. This technique helped minimize nuisance potential but 
had the unfortunate side effect of missing terrain entirely if the scan pattern was narrower than the post 
spacing (the scan pattern was the narrowest near the aircraft). The SUAV technique included all terrain data 
when any part of the rectangle surrounding a post was within the scan pattern. 

Figure 28 shows how DEM posts were scanned for the SUAV project. The scan pattern is the same one 
shown in figure 27. The small green diamonds represent the 3-arc-s DEM posts as re -rasterized from the 
CDTM. Some of the DEM posts identified during the scan process were actually outside the scan pattern. 
The fine green rectangles in the background of figure 28 represent the individual polygons corresponding 
to each DEM post. If any portion of those rectangular polygons was within the scan pattern, the 
corresponding DEM post was included. Therefore, all of the green diamonds shown in figure 28 represent 
DEM posts that would have been used by the algorithm, even if outside the purple scan lines. This method 
ensured that nearby posts were always included in the scan pattern. 
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Figure 28. SUAV DEM post scanning. 
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Once the height of each DEM post near the scan pattern was determined, those posts were converted 
into a two-dimensional matrix similar to the process used for the F-16. However, the range along the 
trajectory prediction centerline was broken into variable length bins, instead of the constant length bins 
used for the F-16. 

The variable bin lengths were implemented on the SUAV as a way to reduce the computational 
workload for the processor on the smartphone; there would be fewer bins further away from the aircraft. 
The SUAV variable bin length was related to the scan width. The bin length was smaller near the aircraft 
(roughly equivalent to the horizontal navigation uncertainty) and larger at a distance. The highest DEM 
post within each bin was used to assemble the overall 2-D profile. 

Circular bin shapes were another method that was used to reduce the computational workload on the 
SUAV smartphone. The F-16 used narrow, rectangular bin shapes in order to result in a higher resolution 
two-dimensional terrain profile as needed for that aircraft. Because of the lower airspeeds and tighter turn 
radius of the DROID, it was acceptable for the two-dimensional terrain profile to be at a lower resolution 
than the F-16 (i.e., fewer bins over the length of the scan). 

Each SUAV bin was represented by a circle of increasing radius. The center of each scan circle was 
located to provide overlap between neighboring bins. Using a circular scan resulted in a very simple 
equation to determine if a given DEM rectangle was within the scan radius for each bin. The purple lines 
in figure 28 are a simplified representation of the outer boundary of all of the scan circles. In theory, the 
circular scans might “miss” a small portion of a DEM rectangle if that portion fit between the overlapping 
circles. However, this was not considered a practical problem because any relevant DEM rectangle 
“missed” at one time frame would be identified in a later frame as the aircraft progressed forward. 

Generic “ Determine Need to Avoid” Module 

The main function of this module was to decide when an avoidance maneuver needed to be initiated. 
This determination was accomplished by comparing the trajectory prediction (output from the 
“Predict Avoidance Trajectories” module) with the two-dimensional simplified terrain profile (output from 
the “Identify Collision Threats” module). When the predicted aircraft trajectory got too close to the terrain, 
the “Determine Need to Avoid” module sent out an avoidance maneuver command to be executed by the 
autopilot. Figure 29 shows the overall concept for this module. 

Once the DEM posts within the scan pattern were identified and converted into a two-dimensional 
matrix, a generalized “built-in” buffer was applied to account for any remaining uncertainties. A primary 
reason for adding a generalized altitude buffer was to account for suspected errors in the DEM data. The 
magnitude of those errors depended on the resolution of the source data and the compression and 
re -rasterization techniques that were used. As a point of reference, the F-16 and the SUAV each used an 
altitude buffer of 30 ft to account for possible errors in the DEM. 

Another reason to add a generalized altitude buffer was to account for known variations in the trajectory 
prediction that had not already been included in the algorithm (such as the effects of gross weight, 
off-standard day conditions, et cetera). 

In order to provide an allowance for vertical variations in the trajectory prediction, the SUAV used an 
altitude buffer of 10 ft (the F-16 used 15 ft for a similar altitude buffer). Another reason to add a generalized 
altitude buffer was to account for vertical navigation uncertainty. The F-16 EGI output an estimate for 
vertical uncertainty; that value was increased by a one- or two-sigma multiplier (depending on the mode 


43 



selected) to determine the value to be used for this portion of the altitude buffer. There was no similar 
vertical uncertainty output available from the SUAV Piccolo II autopilot. 
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Figure 29. “Determine Need to Avoid” module. 

If each of these altitude buffers were directly added to the two-dimensional DEM profile, the result 
could be nuisance-prone because that method would assume that all of the errors were in the same positive 
direction at the same time. Both the F-16 and the SUAV used a combination of each component, utilizing 
a root-sum-square method. The equation for combining the constituent buffers as used on the SUAV project 
is provided in equation (1): 


Total = NAV + (DEM 2 + TPA 2 ) 1/2 ( 1 ) 

where NAV is used as the buffer to account for GPS navigation accuracy , DEM is used as the digital terrain 
buffer, and TPA is used as the trajectory prediction buffer. 

Auto GCAS developers should also consider the need for an additional altitude buffer. The F-16 used 
a tree buffer of 70 ft that was applied across the entire two-dimensional DEM profile. Obviously, many 
trees are shorter or taller than 70 ft. After a number of informal studies, the 70-ft value was settled upon as 
a way to provide some improved protection from tree impacts without excessively increasing nuisance 
potential. The SUAV did not use a tree buffer, because it was known that the flight -testing for this research 
project would be accomplished only over barren desert hillsides. 

Although the concept for this module is very simple, the implementation for future Auto GCAS projects 
will require careful consideration to determine the answer to the question “how close is too close?” 
Determination of the minimum approach to terrain will require consideration of the essential mission 
requirements for the relevant aircraft. Even if the relevant aircraft only has a high-altitude mission 
requirement, it will be appropriate for any built-in altitude pad to be defined at the lowest number practical 
that still provides adequate collision protection. 
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SUA V Auto GCAS “Determine Need to Avoid” Module 


Given that the SUAV Auto GCAS algorithm was based on three possible trajectory predictions, the 
project-specific implementation of this module required three sets of “Determine Need to Avoid” logic. 
Each of the three trajectory predictions (left, straight, and right) was compared with the corresponding 
two-dimensional terrain profile underneath that trajectory. 

When any of the three trajectory predictions intersected with the corresponding terrain profile 
(including any altitude buffers) that direction was no longer considered a valid terrain avoidance option. 
When two of the directions were no longer valid options, the aircraft was allowed to continue since the 
third direction still provided a valid way to avoid terrain. An avoidance maneuver was only initiated when 
the last trajectory prediction intersected with its buffered terrain profile. 

The end result of this process is represented by the example shown in figure 30. The black polygons 
show the flightpath of the test aircraft leading up to an avoidance maneuver initiation. The red “straight” 
trajectory and the yellow “left” trajectory would have intersected the terrain well before the green “right” 
trajectory and therefore were not viable terrain avoidance options. The green “right” trajectory was the only 
remaining terrain avoidance option. When that trajectory prediction intersected the buffered terrain profile, 
an avoidance maneuver was initiated to the right. The philosophy behind this trajectory selection was only 
to avoid the imminent terrain threat (given the assumption that the pilot had lost awareness of terrain 
proximity for any reason). There was no attempt to help the pilot resume the original flight plan. If the pilot 
was lost in clouds or flying at night, the algorithm would help protect against additional terrain threats, but 
eventually the pilot would need to climb to a safe altitude or take some other corrective action. 
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Figure 30. Example of “Avoid to the Right.” 


Nuisance Potential 

Previous ground collision avoidance projects have concluded that “time to avoid” is a much better 
metric than “distance to avoid.” An avoidance maneuver at high airspeeds needs to be initiated at a greater 
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distance from terrain than does a similar avoidance maneuver at low airspeeds. Using “time to avoid” 
automatically accounts for variations in airspeed and acts as a normalizing metric. Using “time to avoid” 
also provides a better indication of nuisance potential. The overall concept of “time to avoid” has been 
implemented in several ways. A “time-to-flyup” calculation was often used within the Auto GCAS 
algorithm to trigger the avoidance maneuver when that value reached zero. Also, an available reaction time 
(ART) calculation has been used as part of post-flight data analyses to provide an assessment of how well 
the algorithm achieved design goals (see the “Available Reaction Time” section below). 

One of the original F-16 Auto GCAS projects in the late 1990s conducted flight tests to evaluate 
nuisance potential in terms of time (ref. 1). It was concluded that any flyup initiated more than 1.5 s earlier 
than necessary to barely avoid hitting the ground would be considered a nuisance by a pilot who was 
accomplishing a normal F-16 low-level mission and was also aware of ground proximity. The Auto GCAS 
FRRP F-16 (ref. 2) confirmed that almost all flyup maneuvers occurred within that 1.5-s criteria. The 
primary exceptions were at very steep dives, where the original nuisance evaluation did not apply. 

Although the 1.5-s value was determined specifically for an F-16 conducting low-level missions, that 
value has also proven useful as a point of reference and design goal for other projects. If any Auto GCAS 
design can be implemented consistent with that 1.5-s value, it will probably not be considered a nuisance. 
Individual Auto GCAS projects can probably relax that 1.5-s design goal, but should only do so when it is 
certain that the resulting nuisance potential will be considered acceptable by the pilot. 

For an autonomous or remotely-piloted vehicle it might be difficult to develop a specific design 
criterion similar to the 1.5-s value of the F-16. Test pilots were able to provide an “anxiety rating” when 
recovering the F-16 in close proximity to the ground that would be difficult to replicate for UAVs. It might 
be appropriate to develop a UAV criterion in a high-fidelity simulation, since the “sight picture” for the 
operator would not be much different than that seen from a ground control station. 

Generic “Avoid” Module 

The main function of this module (fig. 31) was to translate the avoidance maneuver command from the 
Auto GCAS algorithm into an avoidance maneuver that could be executed by the aircraft autopilot or flight 
control system. On any Auto GCAS project, the first step in this process should be to verify that the 
avoidance maneuver command was valid. In practice, that first step has been implemented as simple 
“heartbeat” checks to ensure that the avoidance maneuver command was coming from a system component 
that was still functional. More creative integrity checks may be possible, but care must be taken not to build 
in so many unwarranted checks that the system will not work when it is needed. 

For the F-16 Auto GCAS, the flyup command was a single bit that basically communicated “Initiate a 
Flyup NOW.” The F-16 flight control system had already been pre-programmed to translate that flyup 
command into the various components to result in a flyup maneuver that can be summarized as “roll toward 
wings-level at roughlyl50 deg/s, and pull as much as 5 g until clear of terrain.” The commanded rates and 
peaks for each individual axis were developed as part of previous simulation and flight -testing over a 
number of F-16 Auto GCAS projects. 

The F-16 implementation of this module included some “heartbeat” checks to verify that a flyup 
command was being sent from a healthy avionics system (single-string) to the flight control system 
(quad-redundant). 

The F-16 implementation also used a number of interlocks, which prevented flyup commands from 
being initiated when outside of the intended design envelope (that is, too slow, gear down, aerial refueling 
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door open, excessive uncertainty in the navigation system accuracy, excessive angle of attack, relevant 
failure modes, et cetera). 
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Figure 31. “Avoid” module. 


SUAVAuto GCAS “Avoid” Module 

For the SUAV Auto GCAS project, this module was slightly more complicated than that of the F-16, 
because the Piccolo II autopilot needed to execute three possible avoidance maneuvers (left, straight, and 
right). Each of those avoidance maneuvers had been tuned to reflect the desired response, as discussed in 
the “SUAV Auto GCAS ‘Predict Avoidance Trajectories’ Module” section above. 

The SUAV Auto GCAS implementation was also different from the F-16 implementation in that the 
SUAV did not accomplish any integrity management checks within this module. All of the SUAV Auto 
GCAS integrity checks were accomplished as part of the “input voting plane,” as discussed in the “Generic 
‘Common Interface’ Module” section above. This method was necessary because the SUAV Auto GCAS 
project did not have the option of inserting additional integrity checks into the proprietary Piccolo II 
autopilot. This implementation was less desirable than the F-16 implementation because there existed less 
protection against communication errors. As discussed above, this module could also be made more robust 
by incorporation of a monitor to protect against false requests for avoidance maneuvers. 

Pilot-Vehicle Interface 

For any Auto GCAS implementation intended for a production aircraft, considerable attention must be 
paid toward ensuring that the pilot has adequate system information, presented in a logical manner, while 
not being inundated with information to the point at which it interferes with other essential operations. The 
intended level of pilot interaction with Auto GCAS must also be determined. 

The general pilot-vehicle interface (PVI) philosophy used for the F-16 was to minimize Auto GCAS 
displays and audio annunciations. The intent was for Auto GCAS to execute in the background, remaining 
unseen until needed. 
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In the original version of F-16 PVI, the pilot normally had no warning of an imminent flyup. When a 
flyup initiated, the word “FLYUP” was displayed in the head-up display (HUD) and an audio tone was 
annunciated. Pilots judged that those annunciations were sufficient to communicate why the aircraft was 
suddenly performing an uncommanded maneuver. 

Operational pilots who had flown flight-test versions of Auto GCAS requested the option to display 
chevrons on the HUD that appeared approximately 3 s prior to a flyup and merged into a break-X at flyup. 
Some F-16 test pilots felt that the HUD chevrons could be a distraction and wanted the default to be “no 
chevrons.” The operational F-16 pilots found that the HUD chevrons provided helpful information when 
flying low-level missions. As of the writing of this report, the production F-16 version of Auto GCAS 
implements the chevron display as the default, but pilots were given the option to disable the chevrons. This 
implementation may be re-evaluated after Auto GCAS experience has been obtained in operational units. 

At low airspeeds, the “FLYUP” indication on the HUD was replaced by an “AIRSPEED” indication. 
This indication was intended as a prompt for the pilot to add power, because insufficient airspeed could 
prevent the flyup from completing. The prompt was necessary because the F-16 did not have auto-throttle 
capability, which would allow Auto GCAS to make power changes. 

The F-16 pilots were also provided with several Auto GCAS Mode settings. Most F-16 missions were 
conducted with Auto GCAS in the “NORM” setting. Low-level missions were conducted with Auto GCAS 
in the pilot-selectable “MIN” setting, which minimized nuisance potential by reducing built-in buffers while 
still providing good CFIT protection. 

Most importantly, F-16 pilots were allowed to disable Auto GCAS at any point during a mission, and 
also to stop Auto GCAS flyups already in progress by using a paddle switch on the sidestick. There had 
been considerable debate regarding providing those two pilot controls; the concern was that pilots might 
disable Auto GCAS inappropriately, rendering it unable to prevent CFIT mishaps. However, the final 
decision was to provide the pilot with the methods for disabling Auto GCAS in case unforeseen problems 
were encountered in operational units. Once Auto GCAS is judged sufficiently mature, one or both of those 
disabling controls might be removed if the pilot community concurs. 

Even after considerable evolution of F-16 PVI, it was still considered marginal by the developmental 
flight-test community (see reference 3 for details). The PVI for the F-22 “Line in the Sky” implementation 
of Auto GCAS was also considered marginal by the developmental flight -test community (see reference 4 
for details). A common thread between these PVI design philosophies was the decision to minimize costs 
by avoiding significant changes to audio tones and other aspects of PVI. The short-term cost savings 
achieved by both projects may result in long-term impacts to operational users. The operational 
communities will provide the final judgment on the respective PVI implementations. 

Pilot-vehicle interface was also considered a low priority for the SUAV Auto GCAS project, since the 
project was a limited-scope flight-test demonstration. Although the cockpit in the ground control van 
provided some capability for a pilot to manually fly the DROID, there was insufficient budget to optimize 
the interface for Auto GCAS. One impact was that the pilot did not have the ability to terminate an 
avoidance maneuver already in progress. Also, the setups for test cards could be flown by the ground 
cockpit pilot, but when an avoidance maneuver occurred and terminated, control was returned to the GCO 
and not directly to the ground cockpit pilot. Methods were under consideration to address this topic, but 
were not implemented, during the course of the project. 

A few Auto GCAS displays were provided on a computer-generated HUD overlaid on the video from 
the nose camera, but these were designed more as flight-test aids than production implementations. Any 
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implementation of Auto GCAS on UAVs will need to pay special attention to incorporating the PVI that 
may be appropriate to that particular system. 

Recommendation 8 (R8): Future Auto GCAS projects should carefully assess the tradeoffs 
between short-term PVI cost savings against the potential for longer-term impacts on the user. 

SUAV Mode States 

The SUAV Auto GCAS project was a flight-test demonstration, therefore mode states were not 
designed for a production implementation. However, some consideration was given to basic mode state 
logic. The basic SUAV Auto GCAS modes states were IDLE, STANDBY, ON, and FAIL. 

The IDLE mode state was designed to prevent Auto GCAS modules from being executed. The IDLE 
mode state was also the default mode state during start-up, requiring a manual command from the UI for 
transition to another mode state. 

The STANDBY mode state allowed the Auto GCAS modules to execute, but prevented avoidance 
maneuvers from being initiated. The STANDBY mode state proved useful on both the F-16 and the SUAV 
because it allowed Auto GCAS data to be recorded during checkout flights and nuisance evaluations 
without concern that an unexpected avoidance maneuver might occur. 

The ON mode state allowed automatic avoidance maneuvers to initiate. The ON mode state was the 
typical mode state used during Auto GCAS flight -testing. 

The FAIL mode state was entered when connectivity checks indicated a loss of communication between 
components, or when an error in the data was detected. The loss-of-communication check was disruptive 
on early flights when the smartphone was in the ground control van and telemetry dropouts occurred as the 
DROID was flown close to the hills. The dropouts could have been caused by multi -path interference with 
the telemetry signal. The frequency of telemetry dropouts was dramatically decreased when a directional 
antenna assembly was developed for use with the ground control van. 

Telemetry interference due to terrain proximity could influence many Auto GCAS projects on UAVs 
if the algorithm is hosted on the ground. Improved aircraft antenna design (such as mounting antennas on 
both the top and the bottom of the aircraft) may help, but multi-path reflections off of the surrounding 
terrain and line-of-sight problems with the ground antenna may result in loss of communication just when 
it is needed most. 

Recommendation 9 (R9): Future Auto GCAS projects involving flight-testing of UAVs should 
pay particular attention to telemetry and control links when operating in close proximity to terrain. 

When the Auto GCAS algorithm was hosted with the smartphone on the DROID, FAIL states due to 
telemetry dropout were eliminated and the overall system was much more robust. However, a few FAIL 
states still occurred, due to on-board communication interruptions. 

In the original SUAV implementation, when a FAIL state was annunciated Auto GCAS would not 
initiate an avoidance maneuver and any avoidance maneuvers in progress were immediately terminated. By 
comparison, the F-16 had already implemented a better FAIL state mechanization that allowed avoidance 
maneuvers to continue after a failure. The original SUAV mechanization proved to be suboptimal because 
the aircraft would stop flying away from terrain, forcing the safety pilot to take control. The FAIL state 
logic was re-designed for the last two flights so that an avoidance maneuver would continue if the FAIL 
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condition occurred after an avoidance maneuver initiation. In this case, the avoidance maneuver would 
continue until the safety pilot took control (or communication with the ground control van was restored). 

Recommendation 10 (RIO): Future Auto GCAS projects on UAVs should consider a mode state 
implementation that allows the avoidance to continue even after reaching a FAIL state. 

The obvious problem with that re-designed mechanization would be the situation in which a hard FAIL 
condition occurs and there is no way for the algorithm to know when it is clear of terrain and safe to 
terminate the avoidance maneuver. During SUAV Auto GCAS flight-testing, this condition was not a 
problem because the safety pilot was always in position to take control. In a production implementation, 
timeout logic might be sufficient to allow the aircraft to avoid the terrain that triggered the avoidance 
maneuver in the first place and allow the UAV to fly back the way it came until the FAIL state no longer 
exists. 

The SUAV Auto GCAS project was a flight-test demonstration, and FAIL states needed to be reset 
manually by the UIO. The F-16 implementation allowed for self-recovery from failure states. 

Recommendation 11 (Rll): Future Auto GCAS projects on UAVs should consider a 
self-recovering mode state implementation to resume CFIT protection as soon as the cause for the 
FAIL state no longer exists. 


System Ground Testing 


Prior to flight-testing, a rigorous set of verification and validation ground tests was accomplished for 
every new software-hardware configuration. The primary intent of these tests was to confirm that the 
software was coded as expected and that the hardware interfaces allowed for proper communication 
between components. Some ground tests were also accomplished to verify that there was no 
electromagnetic interference between components. 

The hardware configuration for these ground tests was very similar to the flight-test configuration. All 
of the essential hardware components as shown in figures 11(a) and 11(b) were connected in an HIL 
simulation environment. The HIL setup included a smartphone running the Auto GCAS algorithms 
connected to a UI laptop computer (or a Gumstix® personal computer if simulating a “smartphone on 
aircraft” configuration). The portable ground station provided the necessary interface between the UI laptop 
computer, GCO laptop computer, ground cockpit, and the Piccolo II autopilot. 

The software configuration of each set of ground tests was frozen to match the following phase of 
flight-testing. The most significant difference between ground testing and flight-testing was that the DROID 
dynamics were simulated in the HIL simulation environment hosted within the AFRC Simulation 
Laboratory. The DROID simulation was not very representative of the actual test aircraft, but was still 
adequate to accomplish ground testing. 


Flight-Testing 


The standard set of parameters as recorded throughout each test flight for the SUAV Auto GCAS 
project is given in appendix A. The specialized data analysis techniques that were used are presented in 
appendix B. A flight log for all SUAV Auto GCAS flights is presented in appendix C. The flight log is 
divided into two sections. The first section documents the preliminary flights that were used to obtain basic 
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aircraft response data and accomplish the initial Auto GCAS functionality checks. The second section 
documents the primary Auto GCAS flight tests. Appendix D contains a summary of the open NASA 
discrepancy reports (DR) that existed at the end of the SUAV Auto GCAS project. The main intent for this 
list is to allow the staff on similar future projects to decide if each item warrants improvement. 

Test Objectives 

Prior to formal SUAV Auto GCAS flight-testing, a few flights were conducted with the objective of 
obtaining basic DROID response information during maneuvers that were similar to Auto GCAS avoidance 
maneuvers. These characterization flights were accomplished using normal DROID flight procedures and 
normal DROID autopilot functionality. The data obtained from these flights were not directly applicable to 
an Auto GCAS avoidance maneuver because each axis of the maneuver had to be initiated by separate 
keystrokes (instead of simultaneously). However, the limited data obtained from these flights were 
sufficient to provide a decent starting point for the Auto GCAS algorithm. 

The SUAV Auto GCAS flight-test objectives were to: 

• Accomplish basic functionality checks; 

• Verify Auto GCAS component function; and 

• Evaluate fully integrated Auto GCAS: Evaluate: 

collision avoidance capability; and 
nuisance potential (limited). 

The test flights tended to be conducted in groups based on the location of the test site and whether 
the smartphone was on the ground or on the test aircraft. 

Test Sites 

Three test sites, each site serving a particular purpose, were used for all of the SUAV Auto GCAS flight 
tests. Figure 32 provides an aerial map view of the three test sites. 
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Figure 32. Test site overview. 
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The coordinates for each test site are provided to enable readers to find those locations on Google Earth 
(Google Inc., Mountain View, California). In each case, the coordinates represent the approximate position 
of the ground control van as shown in the figure for that site. 

The North Base test site lies at 34° 59.400’ north latitude and 117° 51.890’ west longitude. The 
North Base test site was the closest location to AFRC and therefore required the least amount of logistical 
effort for test team deployment. This site was also selected because it was where normal DROID operations 
had previously been accomplished. The North Base test site was one of the locations within EAFB airspace 
that had been approved for SUAV operations (as coordinated through the normal flight -test scheduling 
process). 

The North Base test site had the advantage of an existing hard-surface runway (fig. 33). From an 
Auto GCAS point of view, the North Base test site was limited to smooth-terrain test points because the 
entire area is quite flat. 
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Figure 33. North Base test site. 

The first few characterization flights and functional check-flights were accomplished at the North 
Base test site location. The Auto GCAS component functions were also verified at this test site. One of the 
North Base test site flights included the first few smooth-terrain Auto GCAS test points. 

The Rosamond Fakebed test site lies at 34° 52.132’ north latitude and 118° 5.200’ west longitude. 
The Rosamond Fakebed test site offered the slight advantage of small terrain features that could provide 
Auto GCAS test options other than those provided by the predominantly smooth terrain of the North Base 
test site. The main advantage of the Rosamond Fakebed test site was that the logistics of test team 
deployment were much simpler than what would have been required to deploy the test team to a remote 
desert location. 
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There is a small hill (approximately 75 ft tall) on the north side of the lakebed. That hill was used as 
the location for the first few Auto GCAS test points over terrain that was not smooth (fig. 34). The safety 
pilot was located at the top of that hill for those test points. 



Figure 34. Rosamond Lakebed test site. 

The Rosamond Lakebed test site offered no hard surface runway, but the lakebed surface was 
normally dry enough to support DROID takeoff and landing operations. This test site was another of the 
locations within EAFB airspace that had been approved for SUAV operations (as coordinated through 
the normal flight-test scheduling process). 

The GCAS Valley test site lies at 35° 12.208’ north latitude and 1 17° 25.1 16’ west longitude. The 
GCAS Valley test site was selected because it provided a very useful variety of terrain features, and because 
one of the small lakebeds within it provided an adequate takeoff and landing surface for the DROID. The 
specific test locations within the GCAS Valley test site (fig. 35) were selected in order to provide adequate 
areas in which to position the safety pilot and ground observers. 



Figure 35. GCAS Valley test site. 
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The GCAS Valley test site required the most logistical effort for test team deployment. This test site 
was only reached after almost two hours of driving time from AFRC; approximately half of that time spent 
driving on partially-maintained dirt roads. This test site was located directly underneath the Black Mountain 
low-altitude supersonic corridor, and required special scheduling to avoid airspace conflicts with other 
flight-test operations. On each test day, a Notice to Airmen (NOTAM) was issued to alert other pilots to 
the DROID test activity in that area. 

The test area closest to Fremont Peak was about 1.5 miles from the lakebed used for takeoff and 
landing. It required an additional 30-45 minutes to move the safety pilot and ground observers to their 
assigned stations via rough dirt roads. 

Despite the logistical challenges, this test site was well-suited for Auto GCAS flight testing on the 
DROID class of aircraft. Almost all SUAV Auto GCAS flight-testing was accomplished at the GCAS 
Valley test site. This test site included smooth terrain; a small hill (approximately 350 ft taller than the 
surrounding terrain) with safety pilot access to the top of that hill; moderate terrain (approximately 700 ft 
taller than the surrounding terrain) including a small box canyon with safety pilot access on the side of that 
canyon; and a small saddle area for nuisance testing. 

Ground Survey at the GCAS Valley Test Site 


An important consideration for the GCAS Valley test site was whether or not the terrain features 
were actually at the same longitude, latitude, and altitude positions as those indicated by the DEM within 
the NED. The answer was not considered a flight-safety issue because the safety pilot remained the primary 
protection against ground impact. However, a technical problem could have arisen if the actual terrain in 
the GCAS Valley were significantly different than that as shown by the NED, so a ground survey for key 
terrain features within the GCAS Valley was conducted. 

Ground surveys have been a common procedure on past Auto GCAS flight-test projects. On the F-16 
Auto GCAS projects in the 1990s and portions of the F-16 FRRP, ground surveys were accomplished by 
project personnel hiking to the relevant terrain features with handheld GPS units. This same technique was 
also used for the SUAV Auto GCAS project in the GCAS Valley for the valley floor and the accessible 
sides of the hills (only where the terrain was not too steep to walk). 

One of the test sites used by the F-16 FRRP included terrain that was much too steep for simple 
hiking surveys. At that test site the professional surveyors at the NGA were requested to accomplish a more 
formal survey. These NGA surveyors were already stationed at EAFB and conducted surveys like this as a 
normal part of their support for base activities. For inaccessible terrain locations these surveyors used 
standard triangulation techniques to obtain high accuracy. 

The NGA was also requested to support the SUAV Auto GCAS project by surveying the more 
inaccessible portions of the GCAS Valley. From an Auto GCAS perspective it was not necessary to obtain 
a ground survey in a rectangular grid for the entire area; it was only necessary to survey the ridgelines at 
the planned test sites within the GCAS Valley. The ridgelines were the most likely areas to trigger an 
avoidance maneuver, and were also the areas where it was most likely for the test aircraft to get closest to 
terrain (during or shortly after the avoidance maneuver). 

Figure 36 shows the results of the NGA survey for a portion of the small box canyon area. The 
bottom cusp of each white balloon represents the survey altitude at that longitude and latitude. The white 
line below each balloon represents the difference between the survey altitude and the Google Earth 
representation. 
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Figure 36. NGA survey at primary test area. 

The Google Earth graphics were also based on NED data, and figure 36 is considered a good 
depiction of the altitude errors that would be inherent to the Auto GCAS algorithm that was also based on 
NED data. Figure 37 provides an overall summary of the difference between the NGA survey and the NED 
data at the closest NED post to the survey coordinates. 


Mean = 27.0 ft Standard deviation = 13.4 ft 



Difference: NGA survey minus NED 
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Figure 37. NGA survey histogram. 
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The histogram data shown in figure 37 indicate that the survey data were higher than the nearest 
NED post by about 27 ft on average. One survey point was approximately 60 ft higher than the 
corresponding NED post. There were no cases in which the NGA survey data were below the NED data. 

The overall conclusion from the NGA survey was that the NED data were sufficiently accurate to 
provide a viable source for the Auto GCAS algorithm. The 27-ft average error was within the tolerance 
provided by the DEM uncertainty buffer of 30 ft. The scan pattern methodology and the selection of DEM 
posts outside the scan pattern (fig. 28) provided sufficient additional buffering. 

Test Methods 


The primary test methods used were: 

• PARS (to obtain trajectory data); 

• Collision avoidance testing; 

• Mishap scenarios; and 

• Nuisance evaluations. 

Each method is described below. 

Pilot-Activated Recovery System 

The SUAV flight -test technique used was based on the F-16 PARS maneuver. The goal was to initiate 
a maneuver that replicated an avoidance maneuver as closely as was practical. For the SUAV Auto GCAS 
project, PARS maneuvers were initiated by the GCO instead of the pilot, but the intent was the same. 

The PARS maneuvers provided a significant flight-test advantage over Auto GCAS -initiated avoidance 
maneuvers when the only intent was to obtain trajectory data. Auto GCAS avoidance maneuvers require 
that the test aircraft be maneuvered into a particular set of flight conditions over a specific terrain feature. 
The PARS maneuvers could be initiated as soon as the aircraft was set up on the target test conditions, 
regardless of terrain. The extra maneuvering time required to set up for an Auto GCAS maneuver 
significantly impacted test efficiency and effectiveness. On average, SUAV PARS test runs were executed 
at twice the rate of Auto GCAS test runs. 

Collision Avoidance Testing 

The vast majority of SUAV Auto GCAS flight -testing was collision avoidance testing. These tests 
always required the most planning and test team coordination, because the test aircraft was being 
intentionally aimed at terrain. 

The single most important guiding principle for collision avoidance tests was, “Do not rely on Auto 
GCAS to prevent a collision.” Any collision avoidance system under test could reveal unforeseen problems 
at the most inopportune time. Discovering those problems when close to terrain could easily result in a 
mishap, so extra care and control was necessary to maintain test safety. 

In a piloted test airplane like the F-16, this was accomplished by placing all responsibility for avoiding 
collisions on the test pilot. In the case of the SUAV project, all responsibility for avoiding collisions was 
placed on the safety pilot (located on the ground near the test area). The essential point was that the F-16 
test pilot and the SUAV safety pilot were briefed to take control as needed, regardless of how much 
confidence had been developed in the Auto GCAS. 
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Another important guiding principle for collision avoidance tests was, “Add a flight test altitude buffer 
for each new set of flight conditions.” Both the F-16 and the SUAV used a terrain clearance buffer (TCB) 
that was implemented as a flight-test aid. The TCB caused avoidance maneuver initiations to occur at a 
higher altitude than would normally occur with the basic Auto GCAS algorithm. 

The TCB value was specified on the test cards for each run and could be set by the test pilot on the 
F-16 project and the UIO on the SUAV project. The TCB value specified for a given run was dependent 
upon the target test conditions. In general, steeper dives and more dynamic maneuvers led to higher TCB 
values. Once Auto GCAS had been evaluated at higher TCB settings, the same test conditions could be 
repeated at lower TCB settings. 

Some SUAV collision avoidance flight tests were conducted with a TCB value of zero. Those runs used 
whatever buffer was built into the Auto GCAS algorithm, but there was no additional flight-test buffer. 
Tests with zero TCB were only accomplished once the test team was satisfied with the system performance 
established using higher TCB values. When testing with zero TCB the responsibility for avoiding collisions 
remained with the safety pilot. 

A primary goal of the collision avoidance tests was to thoroughly “wring-out” the Auto GCAS 
implementation under controlled conditions prior to conducting nuisance evaluations, which tend to be less 
scripted. On the F-16 project, this goal was accomplished during incremental phases because the emphasis 
was on reaching the nuisance evaluations phase as quickly as practical. It was critical to show that the F-16 
Auto GCAS would not be nuisance-prone under operationally relevant scenarios. On the SUAV project, 
the main emphasis was on demonstrating the portability of the Auto GCAS algorithms, so there was much 
less emphasis on nuisance evaluations. Therefore, nuisance evaluations were only conducted on the last 
two flights of the SUAV project (for more background see the “Nuisance Evaluation Techniques” section 
below). 

On the SUAV project, the general collision avoidance test procedure for a given test run began with 
the GCO commanding the test aircraft into a circular holding pattern (see fig. 38). The holding pattern was 
typically a few hundred feet above the intended test point altitude and at least 500 ft above the valley floor. 
For the example shown in figure 38, the holding pattern was clockwise. Before the test aircraft left the 
holding pattern, the GCO commanded the test aircraft to descend to the intended test point altitude. After 
the test conductor confirmed that the test team was ready to test, the GCO commanded the test aircraft to 
leave the holding pattern and enter the test pattern. 
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Figure 38. Example collision avoidance pattern showing waypoints (WP). 

A sequence of four waypoints was used to establish the test pattern. Waypoints 1 and 2 consisted of 
longitude, latitude, and altitude coordinates located at the tangent points of the holding pattern that remained 
fixed throughout a test mission. Waypoint 3 was located at the “Initial” point for the final run-in to an 
expected avoidance maneuver (represented in figure 38 by the black line between the “initial” point and the 
expected avoidance point at the green dot). The coordinates for waypoint 3 varied, depending upon the 
setup needed for a particular test point. Between waypoints 2 and 3, the test aircraft was usually commanded 
to accelerate or decelerate to the test airspeed. Waypoint 0 was the “aimpoint” for each avoidance maneuver. 
Waypoint 0 established the heading for the final run-in line from waypoint 3. The coordinates for waypoint 
0 varied depending on the aimpoint needed for a particular test point. 

The expected avoidance point was defined on each test card. The coordinates for that point assumed 
that the test aircraft flew exactly along the planned run-in line, but that was not always true because of 
crosswinds or other setup problems. Those coordinates were also used for a countdown display in the 
ground control van. The dark blue line in figure 38 represents the expected avoidance path. That path was 
shown on the test cards to provide the test team with an idea of what to expect for a given test run. 

The primary information communicated on the test cards was whether a given run was expected to 
execute an avoidance maneuver left, straight, or right. However, the actual test event did not always occur 
as expected. In particular, if a given test run was aimed along the crease in a ridgeline, the avoidance could 
go either left or right, depending on small setup variations. Those subtle Auto GCAS algorithm decisions 
were intentional parts of the test. The test team was always ready for the test aircraft to turn in unplanned 
directions. The safety pilot always took control if the aircraft appeared to be headed too close to terrain or 
if it was heading outside the field of view (such as over a ridgeline or into the glare of the sun). 

The test cards also provided the test team with some idea of the specific path the test aircraft might take 
relative to the safety pilot and ground observers. The ground observers were located in key positions relative 
to nearby terrain features to assist the safety pilot when the test aircraft was flying close to those terrain 
features the proximity of which was not easy to judge from the safety pilot perspective (see example 
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in figure 38). If the aircraft remained clear of terrain, the ground observers made periodic “clear” calls on 
the radio. If the ground observers judged that the aircraft was getting too close to terrain, they called for an 
“abort” on the radio and the safety pilot took immediate control. 

When a test run went according to plan and the avoidance maneuver terminated normally, the test 
conductor called “test complete” on the radio. That call was another signal for the safety pilot to take 
control. Therefore, the safety pilot took control on every collision avoidance test run, even if everything 
went according to plan. This procedure was an intentional one, the purpose of which was to eliminate any 
uncertainty as to who was flying the aircraft and when on every collision avoidance test run. 

After taking control on every collision avoidance test run, the safety pilot would first and foremost 
ensure terrain clearance. Once satisfied that the aircraft was well clear of terrain, the safety pilot then 
maneuvered the aircraft back toward the holding pattern. When the test conductor determined that the test 
aircraft was in a good position, control was transferred from the safety pilot to the GCO. The GCO 
maintained the aircraft in the holding pattern until the test conductor coordinated the setup for the next test 
card. The test team became very proficient at executing these test procedures and averaged one collision 
avoidance test run every 5 min. 

Mishap Scenarios 

A few collision avoidance test runs were configured to replicate three scenarios that have occurred in 
real-world UAV and general aviation mishaps. The basic flight conditions for each of these mishaps were 
obtained from the USAF Safety Center (for the UAVs) and the National Transportation Safety Board 
(for the Cessna). 

A top-level description of those mishap scenarios is: 

• During an approach to landing, an MQ-9 was destroyed after hitting some power lines short of the 
runway after a steep descent. The key mishap flight conditions replicated were the bank angle and 
descent rate over smooth terrain. The test airspeed was approximately 10 kn less than for the mishap 
aircraft. 

• During combat support operations in mountainous portions of Afghanistan, an MQ-1 Predator 
(General Atomics, San Diego, California) was destroyed when the aircraft entered a box canyon 
while attempting to cross from one mountain valley into another valley. The key mishap flight 
conditions replicated were the bank angle, dive angle (near level flight), and ingress to a terrain 
feature that resembled a box canyon. Once again, the test airspeed was approximately 10 kn less 
than for the mishap aircraft. 

• During a nighttime cross-country flight over rising mountainous terrain, a Cessna Turbo 182T 
(Cessna Aircraft Company, Wichita, Kansas) was destroyed with two fatalities when the 
established climb rate was insufficient to clear a ridgeline. The key mishap flight conditions 
replicated were the climb rate on a wings-level approach to rising terrain. The exact airspeed at 
impact for the mishap aircraft was not known but was likely about 20-30 kn faster than the test 
aircraft. 

Nuisance Evaluation Techniques 

The primary test technique used for nuisance evaluations was to mimic UAV mission segments that 
could occur during normal operations while also within reasonably close proximity to terrain. The primary 
intent of those tests was to evaluate whether Auto GCAS avoidance maneuvers would be considered a 
nuisance if they occurred during those mission segments. 
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Most normal UAV operations are conducted many thousands of feet above terrain, where the risk of 
CFIT is very low. However, a number of situations exist within which the risk of CFIT is higher. 

Any operations in mountainous regions could place the UAV near its performance ceiling, forcing the 
UAV to attempt ridge crossings in the passes between mountain peaks in order to get from one valley to 
another (as in the MQ-1 mishap). Examples of this scenario include combat operations in mountainous 
regions such as Afghanistan, but could also include peacetime missions in support of firefighting operations 
over mountainous areas within the CONUS. In addition, even if the UAV is not flying near its performance 
ceiling, air traffic control limitations could place a ceiling on operations that constrains the UAV to an 
altitude lower than surrounding mountain peaks. 

Two UAV mission segments were selected for SUAV Auto GCAS nuisance evaluations. These were 
called “ridge crossings” and “valley patrols.” In order to obtain a more qualitative evaluation, both of these 
segments were planned for a pilot manually flying those mission segments. A system test of Auto GCAS 
could also have been flown under GCO control using the normal technique using waypoints for both 
mission segments. 

Ridge crossing tests were constrained by the requirement that the safety pilot keep the test aircraft in 
sight at all times. The test aircraft could not cross a ridge above the safety pilot and then continue across 
that ridge beyond where the safety pilot would lose visual contact. Therefore, a more practical location was 
selected that allowed the safety pilot to be positioned where the test aircraft would remain in sight 
throughout the test run. The only location at GCAS Valley with reasonable dirt road access was a small 
saddle area. This saddle allowed limited ridge -crossing testing, but the terrain was only slightly higher on 
both sides of the saddle (fig. 39). 



Minimum safe 
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Figure 39. Ridge crossing test location. 

The test cards for ridge crossings listed a minimum safe altitude that would keep the test aircraft clear 
of all terrain within the designated test area (as shown in figure 39). The minimum safe altitude was based 
on MSL altitude as provided by the Piccolo II autopilot GPS/INS. The pilot was directed to stay above that 


60 


minimum safe altitude while also staying within the test area, a large display of each of which was visible 
directly in front of the pilot. This method was used to attempt to simulate typical mission constraints that 
might be placed on a UAV operator. 

If the pilot flew directly over the saddle while also above the minimum safe altitude, there would be at 
least 185 ft of clearance. The intent was to show that the saddle could be crossed at a reasonably low altitude 
without the Auto GCAS algorithm inducing a nuisance avoidance maneuver. 

If the pilot strayed close to the boundary of the test area, the clearance would have been approximately 
75 ft. The safety pilot was in a good position to take control if a run became too close to terrain on that side 
of the saddle. 

Valley patrol tests were intended to represent a mission segment in which a UAV was tasked to loiter 
within a mountain valley while conducting normal surveillance operations. Similar to the ridge crossings, 
the pilot was directed to stay above a minimum safe altitude while also staying within the test area (fig. 40). 



Fremont Peak 


Ground control van 
(on lakebed) 






2, Map data: Google, SIO, NOA, 


Figure 40. Valley patrol test area. 

Given those mission constraints, there would be at least 150 ft of clearance anywhere within the test 
area. The examples in figure 40 show typical racetrack patterns, but the pilot was allowed to follow any 
pattern as long as the test boundary and altitude constraints were observed. The intent was to show that 
missions of this type could be conducted at reasonably low altitude without the Auto GCAS algorithm 
inducing a nuisance avoidance maneuver. 

Valley patrol tests were planned so that the safety pilot and ground observers could be located where 
they could monitor the test area boundaries and abort the run if the test aircraft strayed too far outside those 
boundaries. 

Ridge crossings and valley patrols were planned to be accomplished either with the normal 
three -trajectory Auto GCAS algorithm (allowing left, straight, or right avoidance maneuvers) or with the 
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multi-trajectory option disabled (allowing only straight avoidance maneuvers). The intent was to provide a 
comparison of the nuisance potential of those differing design approaches. 


Test Preparation 

It may be possible to accomplish Auto GCAS flight-testing by selecting a likely terrain feature and 
aiming the aircraft at that feature. However, more useful test results and safer test conduct can be achieved 
when the test team knows what to expect for each test run. A powerful, integrated flight-test planning tool 
was developed in support of the SUAV Auto GCAS project. That tool consisted of two primary 
components: 

• The SUAV Auto GCAS avoidance maneuver simulation, and 

• The avoidance maneuver visualization using Google Earth. 

The combination of these two components considerably enhanced flight-test planning. The avoidance 
maneuver visualization component also greatly improved flight-test data analysis, as discussed in the “Test 
Results” section below. 

SUAV Auto GCAS Avoidance Maneuver Simulation 

A customized simulation of SUAV Auto GCAS avoidance maneuvers had been developed early in the 
project as a design tool. That simulation enabled the user to establish aircraft setup conditions relative to 
terrain features and initiate the simulation. The results then provided an indication of where and when the 
avoidance maneuver was expected to occur. At a more fundamental level, the simulation also indicated 
whether an avoidance maneuver would occur, because some setups would not necessarily lead to an 
avoidance maneuver. For SUAV Auto GCAS, the simulation also predicted whether the avoidance 
maneuver would be executed to the left, straight, or right. 

One of the original purposes for this simulation was to provide software programmers with a functional 
reference model. The simulation provided test cases that could be used to compare with results from the 
Java™ software hosted on the smartphone. 

The SUAV Auto GCAS simulation used the same modular architecture and the same simplified 
kinematic models for the avoidance maneuver dynamics as those described in the “SUAV Auto GCAS 
Software Components” section above. The simulation also used a subset (limited to the SUAV Auto GCAS 
test sites) of the same DEM data that the smartphone would use. 

The use of a simplified Auto GCAS simulation for this purpose has a history that goes back to early 
F-16 Auto GCAS flight-testing in the 1990s. At that time, the simulation was successfully used for 
flight-test planning and to determine the abort altitudes required to observe flight-test safety procedures. 
The simplified kinematic models in that F-16 flyup simulation were initially generated based on hundreds 
of high-fidelity six-degrees-of-freedom simulation runs provided by Fockheed Martin. Those kinematic 
models were later verified using flight -test data. The F-16 flyup simulation was also used for trajectory 
reconstruction in over a dozen F-16 CFIT mishap investigations. 

In the 1990s, the utility of the output from the F-16 flyup simulation was of course constrained by the 
current state of the art for computer graphic visualization tools. It was possible to feed the predicted 
trajectory from the simulation (or the actual trajectory from flight -testing) into three-dimensional computer 
graphics software to generate views of the flightpath of a run relative to the intended terrain, but that process 
was labor-intensive and each run could take hours to generate from a single perspective. More recent 
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computer graphics tools have helped overcome that constraint for the SUAV Auto GCAS project as 
described in the following section. 

Avoidance Maneuver Visualization 

Various figures in this report have already provided examples of the SUAV Auto GCAS visualization 
tools (figs. 22, 30, and 38). The tremendous utility of these tools was enabled by linking the output from 
the SUAV Auto GCAS simulation to provide inputs into Google Earth. This linking was accomplished by 
using MATLAB® (The MathWorks, Natick, Massachusetts) to feed the outputs from the simulation into 
standard Google Earth graphic functions. The result was keyhole markup language, or KML, files that could 
be viewed easily in Google Earth. (Keyhole Corp., Mountain View, California, was a technology company 
purchased by Google in 2005). 

Examples of the types of information output from the simulation into Google Earth included: 

• The planned flightpath leading up to the avoidance maneuver; 

• The predicted flightpath during the avoidance maneuver; 

• The scan pattern used at avoidance maneuver initiation; 

• The highest terrain “threat” at a given range from the aircraft; 

• The height of the combined TCB and built-in buffers above the highest terrain at a given range; 

and 

• Alternative trajectories that were not selected. 

The DEM data were also represented by placing Google Earth polygons around each terrain post, 
but these data were not output directly from the simulation. 

An example of how Google Earth was used to help visualize the setup for a particular flight -test 
point is shown as a top view in figure 41. This figure shows a top view of the terrain near the scan pattern 
used by the Auto GCAS algorithm at the instant at which the right avoidance maneuver was predicted by 
the simulation. The left and straight trajectory predictions were also calculated by the simulation, but were 
already rejected as invalid avoidance options prior to this point in time. 
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Figure 41. Circular terrain scanning example 1. 
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The green circles in figure 41 illustrate how the expanding scan pattern can be simplified by 
combining the navigation uncertainty and track uncertainty (as described in the “SUAV Auto GCAS 
‘Identify Collision Threats’ Module” section above) into expanding circles centered at increasing ranges 
along the predicted trajectory. 

Although this circular scan technique may theoretically “miss” terrain features located near the 
intersection of these circles, missed terrain features have not been a problem in practice. If a terrain feature 
happened to fall into the “crevice” between two scan circles, that terrain feature was always detected by the 
scan during a following frame. Additional conservatism was built into the scanning technique because the 
individual DEM posts were represented by rectangular polygons as used by the Auto GCAS algorithm. 
DEM posts well outside the scan pattern were detected whenever a tiny corner of the rectangular polygon 
was within any of the scan circles. 

The way in which the circular scanning technique identifies the highest terrain post in the vicinity is 
illustrated in figure 42 by a perspective view of the same trajectory prediction as that shown in figure 41. 
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Figure 42. Circular terrain scanning example 2. 

The orange polygons in figure 42 represent the way in which the scanning algorithm interprets each 
terrain post. The relevant terrain posts are represented by the multi-colored balloons in figure 42. The terrain 
post height is at the cusp underneath each balloon, which is the same height as the corresponding flat, 
horizontal, orange polygon. Each post has been re-rasterized from the CDTM data. 

The smallest circle in figure 42 represents the first terrain scanning area and was closest to the location 
where an avoidance maneuver was predicted to initiate. The only orange polygon within the bounds of that 
smallest circle was the one corresponding to the first balloon. Therefore, the height of the circle is set at the 
same height as the balloon. 
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Scan circles 2 and 3 (in blue) overlap more than one orange polygon. The highest orange polygon was 
the one established by the post represented by the dark blue balloon. Therefore, scan circles 2 and 3 are set 
at the same height as the dark blue balloon. 

That pattern continues with the light blue scan circle 4 set at the same height as the light blue balloon. 
The two green scan circles 5 and 6 are set at the same height as the green balloon, and so on for the yellow 
scan circle 7 and the red scan circle 8. 

The dark blue curving line in figure 42 represents the trajectory prediction for that run. The dark blue 
vertical lines help visualize the height of the trajectory above the ground at the center of each scan circle. 
It can be seen that the dark blue trajectory line is above ah of the scan circles up to and including the yellow 
scan circle. Therefore, the terrain represented by all of those circles would not have been high enough to 
trigger the avoidance maneuver. However, the red scan circle is above the dark blue trajectory prediction, 
and therefore the terrain post represented by the red balloon is the one that triggered this particular 
avoidance maneuver. 

Also note that the red scan circle in figure 42 is barely touching the orange polygon corresponding to 
the red balloon. This occurrence was very common. One frame earlier, the trajectory prediction would have 
been slightly farther from the red post, the red scan circle would have been at a much lower height, and 
therefore an avoidance maneuver would not have been initiated at that point in time. 

A11 of the scan circles in figure 42 represent no added built-in buffer or TCB. If the simulation of this 
run had used a higher value for the TCB, the tops of ah of the scan circles would have been higher, but the 
yellow scan circle would probably have been high enough to trigger the avoidance sooner. 

Once the information shown in these Google Earth representations was understood, the predicted 
trajectory for a given simulation run could be assessed very quickly to see if it would yield the desired 
results. If the resulting avoidance maneuver went in the wrong direction, or was triggered by the wrong 
piece of terrain, the initial conditions were adjusted until the desired results were obtained. 

During early SUAV flight tests, the Google Earth visualization tools were used to identify initial points 
and aimpoints that would maximize the likelihood that the avoidance maneuver would occur in a predictable 
direction. The avoidance maneuver direction was not always intuitive because the P-factor effect made the 
trajectory prediction asymmetric. Test day winds also influenced the avoidance maneuver direction selected 
by the Auto GCAS algorithm. 

As the test team became more experienced with test run setup and at judging the rate at which the test 
aircraft approached terrain, the visualization tools were used to identify initial points and aimpoints that 
challenged the Auto GCAS algorithm by making the optimal avoidance maneuver direction more 
ambiguous, such as aiming directly at the crease in a ridgeline. 

The end result of the process was a test matrix that efficiently captured as many setup variations as 
were practical for a short flight-test project. After the test matrix was established and approved by project 
management, the Auto GCAS simulation was also used to generate test cards for each individual run in the 
test matrix. 

Test Cards 

An example test card is shown in figure 43. 
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Card # Auto GCAS Flyup 

Run ID: GMH23c 

g Box Cyn R2 

Priority: 1 


| TCB=0, t 


s =STBY, Lat= 35.191666*. Long=-117.439333* 


/P: Level Flight Setup: 

IAS: 45 knots 

Alt: j” 3145 ff wgs84 


Need: 

•Min AGL>40ft 


Hdg: “2~5“degT * Safety Pilot Concurs 


Target Plyup Conditions: 
Dive: 0 deg (0 ft/min) 
Bank: 0 deg 
IAS: 45 knots 


ft wgs84 
ft 

215 degT 


Alt: J 3145 
At SP: “ ^r'ftAGL 
Hdg: 



I AP 
| State 

Tracker 

IAS 

knots 

Altitude 
| ft wgs84 

Bank 

deg 

Heading 

deg 

Vrate 1 
knots | 

A 

GCO/P 

ON 

WP-99 

ON 

55 

ON 

3400 

AUTO 

AUTO 

AUTO 


B ON 

ModiW C CaU 

C ON 

GCO/P TC call 

D ON 

GCO/P WP-0 


45 


, flN AUTO AUTO AUTO 

3145 | 

, 2^4 AUTO AUTO AUTO 

3145 j 

ON AUTO AUTO AUTO 

3145 


Run ID: GMH23c 


Execution: 

1. Start clockwise in Holding Pattern (AP State A) 

2. Set AP State B when ready to test 

3. Set AP State C near WP2 

4. Set AP State D at WP4 

5. Auto Flyup Expected atWP6 

6. Safety pilot takes control after termination (run complete) 

7. Resume Holding Pattern above 3400 after SP/GCO coordination 
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Figure 43. Example test card. 

The left-hand side of the test card was primarily intended for the test conductor and the test team in the 
ground control van. In addition to various test-unique SUAV information, the test card also showed basic 
setup information that would be useful for any Auto GCAS test, such as the: 

• TCB value and coordinates for initiation of the expected avoidance maneuver; 

• Specified level flight setup (versus diving); 

• Target conditions for the avoidance maneuver; 

• Sequence of autopilot states; and 

• Test execution sequence. 

The upper right-hand side of the test card showed a top-down Google Earth view of the planned test 
run and was used by all team members to visualize the expected results. In particular, this portion of the 
test card was intended to help the safety pilot and the ground observers know where the test aircraft would 
be approaching terrain, and the expected direction of the avoidance maneuver. During test missions, the 
same waypoints used to generate the test pattern on each individual test card were also replicated on a large 
high-definition display visible to all members of the test team in the ground control van. 

The lower right-hand side of the test card was primarily intended for those runs during which a test 
pilot was flying the aircraft from the ground cockpit. This Google Earth image provided the test pilot with 
a view along the planned run-in line (the dashed black line). The green circle showed the pilot an aimpoint 
for runs at zero TCB. The green triangle showed the pilot an aimpoint for runs with a TCB of 200 ft. 

Much of the information shown on the test card was pre-established in pre -configured PCC files for 
each individual run. Therefore, when the test conductor called for a particular test card number, it was easy 
to configure the PCC for that run. The test conductor called out each autopilot state at the appropriate point 
in the test pattern and the GCO commanded the PCC to that state. 
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The expected coordinates for the avoidance maneuver initiation were entered into a countdown timer 
calculation on the UIO laptop, and the results displayed to the test conductor. That countdown timer used 
a simple equation based on the current distance to the initiation point and the current velocity of the test 
aircraft. The test conductor provided a radio call at 10 s out and then a countdown from 5 s. This method 
worked reasonably well as long as the test aircraft was somewhat stabilized on test conditions and the winds 
weren’t very high. Even on runs when the countdown timer did not exactly predict the timing of the 
avoidance initiation, the 5-s countdown helped everyone on the test team know that an avoidance maneuver 
was imminent. 

Data Recording Limitations 


The SUAV Auto GCAS project experienced advantages and disadvantages associated with using the 
Android™ platform smartphone as the primary source of post-flight data. One advantage was that 
the smartphone provided the ability to record data that was internal to the Auto GCAS algorithm (similar 
to a data pump on a mux bus). It was not necessary to develop and pay for a separate flight-test 
instrumentation system for that type of internal test-data recording. Another advantage was that the data 
were recorded on the same computer that was hosting the Auto GCAS algorithm, avoiding the potential for 
time synchronization problems that could have occurred with data being recorded on an independent device 
after being fed through other system components. 

The disadvantages have been discussed in the “Host Computer Requirements” section above. In the 
context of total smartphone storage capacity, the design constraint was that Auto GCAS data were only 
recorded at the initiation of each avoidance maneuver. The F-16 recorded Auto GCAS data throughout the 
flight, which was much more useful for assessing nuisance potential in situations in which flyups did not 
activate. In the context of overall smartphone throughput capacity, the primary design constraint was the 
rate at which flight-test data could be recorded without interfering with the basic Auto GCAS functions. 

The combination of these two design constraints led the team to decide to only record trajectory 
prediction and scan pattern data at the initiation of an avoidance maneuver. Both of those data types 
consisted of a moderately-sized array of data. Attempting to record the trajectory prediction and scan pattern 
arrays at every time frame during the run-in could have stressed both the throughput capacity and the storage 
capacity of the smartphone. If the throughput capacity were stressed, the Auto GCAS algorithm might not 
function properly. 

The F-16 Auto GCAS was not limited in the same way with respect to recording of trajectory prediction 
and scan pattern data. The F-16 used an ethernet from the computer hosting the Auto GCAS algorithm to 
the data recording device. That ethernet path provided sufficient high-capacity throughput to record all of 
the trajectory prediction and scan pattern data throughout the entire test flight. This capability was a 
tremendous advantage over the SUAV Auto GCAS implementation because it enabled post-flight data 
review of maneuvers that came close to a flyup but did not actually initiate a flyup. 

Recommendation 12 (R12): Future Auto GCAS test projects using a smartphone as the data 
recording device should consider implementing a recording method that provides data throughout 
the flight, not just when avoidance maneuvers occur. 

It may not be necessary to record trajectory prediction and scan pattern data throughout the entire test 
flight. It may be possible to record those data at a slower rate (such as every other frame) or only when the 
predicted time to the avoidance maneuver drops below a predefined value (such as 5 s). The extra ability to 
analyze post-flight data would probably be worth the additional design effort. 
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In order to accommodate the extra throughput that is required, some portion of the standard set of data 
recorded throughout the test mission may need to be sacrificed. Some of those “always recorded” 
parameters may need to be deleted, or some may need to be recorded at a slower rate. The standard set of 
parameters as recorded throughout each test flight for the SUAV Auto GCAS project is given in 
appendix A. 


Test Results 

One participant in the SUAV Auto GCAS test project described the results by stating, “It worked 
surprisingly well.” That somewhat cryptic description is actually a good overall summary, because the 
system did work better than expected given that the entire project was conceived as a low-budget 
demonstration effort. 

There was never the intent that this demonstration effort directly apply to a production implementation. 
However, there was always a vision that the results might be good enough to form a basis for follow-on 
efforts. The results validated the potential for the new technology concepts and opened the door to several 
follow-on efforts. The overall assessment of SUAV Auto GCAS is divided into the following areas: 

• Excellent CFIT protection, 

• Adequate nuisance potential, and 

• Outstanding modular technologies. 

Controlled Flight Into Terrain Protection 

There were a total of 61 Auto GCAS events that were included in the post-flight analysis process. This 
includes almost all test runs on which an avoidance maneuver was initiated by Auto GCAS, but does not 
include PARS-type avoidance maneuvers. These events do not include another three dozen runs from flights 
7, 8, 9, and 10, when the telemetry reception was especially poor (before the directional ground antenna 
was developed). 

Valid initiations occurred on 52 of the 61 runs. The nine invalid initiations were induced by residual 
telemetry problems caused by incorrect setup or aiming of the directional antenna assembly. 

The primary measure of CFIT protection was, “How close did the aircraft get to the rocks?” This 
question was addressed using the minimum AGF value reached during a recovery. All AGF values, 
including minimum AGF, were obtained by comparing to the NED truth source as described in the 
“Comparison to Digital Terrain Truth Data” section of appendix B. 

Of the 52 valid initiations, 42 resulted in a usable minimum AGF value. Eight cases did not obtain a 
usable minimum AGF value because the safety pilot diverted the flightpath before reaching the minimum 
AGF location. In those cases, the safety pilot took control because the ability to judge terrain clearance was 
degrading (due to a combination of distance and other terrain in the background), not because of a problem 
with the trajectory of the Auto GCAS avoidance maneuver. Two of the unusable minimum AGF cases were 
due to FAIF conditions that were modified in later software updates. 

Figure 44 shows “how close the aircraft got to the rocks” using a histogram for the 42 runs that resulted 
in a usable minimum AGF value. 
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Minimum AGL (all terrain) 



Minimum AGL (referenced to TCB) 
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Figure 44. Minimum AGL (mountainous and smooth terrain). 


Because the test runs were accomplished in a buildup manner, they tended to progress through TCB 
settings of 200, 100, and 0 ft. In order to show all of the data on the same plot, the TCB was subtracted 
from the actual minimum AGL value obtained from each run. This effectively shows “how close the aircraft 
would have come to the rocks if TCB had been set to zero.” 


Most of the runs in figure 44 show that the aircraft cleared the buffered “rocks” by 100 ft or more, with 
a mean of 142 ft. None of the 42 runs penetrated the TCB. This shows that the combination of the scanning 
techniques and the built-in buffer of 40 ft worked quite well to minimize the potential for terrain impact. 

One run would have been within 25 ft of the “rocks” if the TCB had been set to zero (the test run had 
a TCB setting of 100 ft). That particular run was one during which the actual trajectory during the avoidance 
maneuver went far outside the scan pattern at initiation. It is suspected that this deviation was caused by a 
significant change in winds after the avoidance was initiated. The effects of non-steady winds were 
discussed above, and warrant additional consideration on future Auto GCAS systems. This case shows the 
way in which non-steady wind effects could reduce CFIT protection if future Auto GCAS algorithms do 
not account for those effects. 

The data in figure 44 represent all of the usable minimum AGL data regardless of the type of terrain 
along the flightpath. Almost all of those runs were over mountainous terrain. Only a few runs were 
conducted over smooth terrain (a dry lakebed) because that terrain was not considered sufficiently 
challenging to the system. The two runs over smooth terrain that provided usable minimum AGL data are 
shown in figure 45. As expected, these runs recovered at a minimum AGL that was just above the built-in 
buffer of 40 ft. 
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Figure 45. Minimum AGL (smooth terrain). 

The data in figures 44 and 45 indicate that the SUAV Auto GCAS demonstrated excellent CFIT 
protection given the basic design that was implemented for this demonstration effort. 

Nuisance Potential 

Providing a measure of nuisance potential is more problematic than providing a measure for CFIT 
protection. Nuisance potential of a generic UAV is a more subjective measure that will almost always 
depend on the perspective of the individual UAV operator as well as on the mission of a particular UAV. 

Most Auto GCAS nuisance evaluations have been accomplished by conducting a series of operationally 
relevant tasks and asking the pilot to qualitatively evaluate the nuisance potential of any Auto GCAS 
avoidance maneuvers encountered. That type of subjective evaluation provides a valid overall indication of 
nuisance potential but does not establish a quantitative boundary for when an avoidance maneuver would 
be considered a nuisance. 

Available Reaction Time 

As discussed above, nuisance criterion flight tests were conducted on an F-16 in the 1990s. This study 
was the only known analytical flight-test study specifically planned to develop a criterion for Auto GCAS 
nuisance potential. The F-16 study was accomplished by allowing pilots to initiate avoidance maneuvers at 
progressively lower altitudes until each pilot reached a comfort threshold for that maneuver. The end result 
was a quantitative nuisance criterion for typical low-altitude maneuvering for F-16 missions. 

The F-16 nuisance criterion indicated that any Auto GCAS avoidance maneuver initiated more than 
1.5 s earlier than necessary to avoid hitting the ground, would be considered a nuisance by an F-16 pilot 
aware of ground proximity. That time-based metric was considered much more applicable than a 
distance-based metric. The term “available reaction time” (ART) has been used as one way to describe that 
time-based metric. 
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A similar analytical study to develop an Auto GCAS nuisance criterion for UAVs has not been 
conducted. It is suspected that the operator of a UAV would accept avoidance maneuver activations at 
higher ART values than the 1.5-s threshold for F-16 pilots. An Auto GCAS nuisance criterion for a UAV 
would probably depend on a number of additional relevant factors, such as: 

• The size of the UAV; 

• The maneuverability of the UAV ; 

• Whether the UAV is remotely piloted or autonomous; and 

• Whether direct line-of-sight control or a satellite link were being used (which determines the 
amount of delay in the two-way control link). 

Since many of these factors will be platform-dependent, it is probably not appropriate to define a 
generic nuisance criterion that will work for all UAVs. However, it should be practical and necessary to 
develop a nuisance criterion that makes sense for each platform by using simulators combined with in-flight 
pilot experience. It will be essential for Auto GCAS designers on future UAV projects to have some kind 
of guidance regarding nuisance potential so that design tradeoffs can be made. 

Recommendation 13 (R13): Future Auto GCAS projects on UAVs should develop a nuisance 
criterion specific to that project. 

An indicator of the nuisance potential as experienced on the SUAV Auto GCAS project can be obtained 
by inspection of ART. Available reaction time was defined as the amount of time after initiation of the Auto 
GCAS maneuver that the same maneuver could have been delayed and barely avoided terrain. The premise 
of the ART calculation was to determine the amount of time available for a pilot to react if an Auto GCAS 
maneuver were not initiated. A negative ART indicates that the avoidance maneuver would not prevent the 
aircraft from flying into the terrain, or, in this case, the terrain plus TCB. A formal study has not yet been 
accomplished to quantify the ART nuisance boundary for UAVs similar to the test aircraft. The ART was 
not determined from a qualitative pilot opinion but was based on an extrapolation of the actual aircraft states 
combined with the trajectory of the actual avoidance maneuver for a given test run. The method for 
determining ART values on the SUAV Auto GCAS project is described in appendix B. 

A total of 43 runs provided usable ART values. A number of runs did not provide usable ART values, 
usually because the safety pilot took control and ART could not be determined from the limited data 
available for those runs. 

The ART values obtained during SUAV Auto GCAS tests are shown in figure 46. Even though these 
values cannot be compared to a UAV nuisance criterion, they still provide some helpful insight into the 
overall conservatism of the SUAV Auto GCAS algorithm and the consistency from run to run. 
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Figure 46. Available reaction time. 

As expected, the ART values shown in figure 46 tend to be higher than the 1.5-s criterion of the F-16. 
The mean ART value of 3.5 s might still be quite adequate for a UAV. The highest ART value 
(approximately 7 s) might be considered a nuisance for UAVs. 

UAV Mission Segments 

Since the DROID was not a production platform having a well-defined mission, operationally relevant 
tasks could not be selected from an existing list. However, as previously discussed, ridge crossings and 
valley patrols were the two mission segments identified with some operational relevance to UAV missions. 
Only a few of each task type were conducted near the end of flight -testing because these were considered 
lower-priority tests for this project. 

All of the ridge crossing and valley patrol tests were conducted with the TCB set to zero. Higher TCB 
settings were not used because the intent was to accomplish these runs as if they were portions of an 
operational mission in which no flight -test buffers would be added. A buildup approach was used by starting 
new runs approximately 200 ft above the test card minimum safe altitude that would be used on the final 
run. This approach provided the pilot in the ground cockpit the chance to become familiarized with the 
visual cues available on the cockpit video display and to get an idea of the overall setup for each run. 

Seven ridge crossings were accomplished on flight 20, including two buildup runs that were 200 ft 
higher than the final runs. The ridge was crossed in both directions (roughly west to east and then east to 
west). Five runs were accomplished with the Multi -Trajectory option set to ON, providing the Auto GCAS 
algorithm with the option to use left, straight, or right avoidance maneuvers. All five of those runs crossed 
the ridge without any indication of the need for an avoidance maneuver. The aircraft crossed the ridge as 
close as 196 ft AGL. 
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Two additional runs were accomplished with the Multi-Trajectory option set to OFF. This setting forced 
the Auto GCAS algorithm to only use the straight trajectory for avoidance maneuvers. One of these runs 
crossed the ridge at approximately 175 ft AGL, but without an avoidance maneuver. 

The second run with the Multi-Trajectory option set to OFF showed an indication of a straight 
avoidance maneuver, but the aircraft did not react. This miss was quickly traced to a setup problem with 
the Gumstix® personal computer. This setup problem did not invalidate the other ridge crossing runs 
because the main goal was to determine whether nuisance activations would occur. However, this last run 
with the Multi-Trajectory option set to OFF, did indicate a possible nuisance activation. A pilot assessment 
would be needed to determine whether that particular avoidance would have been considered a nuisance. 
If the aircraft had reacted to the initiation, it is likely that the maneuver would have been very short, and 
the pilot may not have considered it a nuisance given the low altitude. 

An example visualization aid for the ridge crossing with the lowest AGL is shown in figure 47. This 
figure shows the flightpath followed by the DROID, with the superimposed wingspan of an MQ-9 (the 
white lines between the red and green “wingtips”) to represent a medium-to-large UAV. This figure 
provides a good perspective of how closely an MQ-9 could have crossed that ridge without triggering an 
avoidance maneuver. 
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Figure 47. Ridge crossing test. 

A few valley patrol tasks were attempted on flight 2 1 . Part of flight 2 1 had been dedicated to the final 
collision avoidance runs with the smartphone installed on the test aircraft. Since it was already late in the 
day, the decision was made to only attempt valley patrol tasks with the Multi-Trajectory option set to OFF. 
The previous flight had provided confidence that tasks executed with the Multi-Trajectory option set to ON 
would be unlikely to show any avoidance maneuvers at the planned altitudes (at least 150 ft AGL with no 
ridge crossings). 

The first valley patrol pass was conducted in a counterclockwise direction as a buildup run at 200 ft 
above the minimum safe altitude shown on the test cards. There were no avoidance maneuver indications 
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on this pass. While attempting to set up for a lower-altitude pass (at the minimum safe altitude), a straight 
avoidance maneuver occurred. This avoidance maneuver occurred well away from the safety pilot and 
terrain clearance could not be properly judged from that distance. In this situation the safety pilot took 
control and maneuvered the aircraft back toward the holding pattern. 

The third valley patrol pass was intended to be a clockwise pattern at 200 ft above the minimum safe 
altitude. However, during the setup another straight avoidance maneuver occurred. This maneuver occurred 
even further away from the safety pilot than had the avoidance on the first valley patrol pass, so the test 
team decided not to attempt any more nuisance evaluations on that flight. 

The overall observations made during the valley patrol tests confirmed the general expectations. When 
the Auto GCAS algorithm was constrained to only use the straight trajectory, the occurrence of avoidance 
maneuvers was not intuitive and could happen at surprising locations. This occurrence was partially because 
of the very low climb performance that was being modeled (in order to replicate a medium-to-large UAV). 
The low climb performance led to avoidance maneuver initiations even when terrain features were several 
thousand feet away from the test aircraft. The occurrence was made even less intuitive because of the way 
the P-factor effect was modeled within the Auto GCAS algorithm. As modeled, the P-factor effect caused 
the “straight” trajectory prediction to be a long, curving flightpath to the left. The pilot could not simply 
look straight ahead to see possible terrain conflicts because the trajectory as adjusted for the P-factor effect 
could trigger from terrain well to the side and was not easy to visualize. 

Another factor that diluted these nuisance evaluations was the setup of the ground cockpit. In an ideal 
setup, control would be returned directly to the pilot immediately after an avoidance maneuver had 
completed, but because of the way in which the ground cockpit was set up during these tests, when an 
avoidance maneuver was complete, control reverted to the GCO. The pilot could resume control by hitting 
a button on the ground cockpit, but it was not always obvious when that button was active. This setup could 
have been easily improved, but with cost and schedule impacts to the ground control station that were 
determined to be out of scope. 

Avoidance Maneuver Termination 

An Auto GCAS nuisance evaluation can also be influenced by the timely termination of avoidance 
maneuvers. If an avoidance maneuver lasts too long, it will undoubtedly be considered a nuisance. 
Conversely, even if a pilot feels an avoidance maneuver may not have been necessary, it may not be viewed 
as a nuisance as long as the maneuver was very short in duration (pilots have described this occurrence as 
a “speedbump”). 

During the F-16 Auto GCAS FRRP (ref. 2), a quantitative criterion was used to assess flyup maneuver 
duration. That criterion was originally developed during F-16 Auto GCAS flight-testing in the 1990s. The 
resulting criterion specified that a flyup must terminate when the flightpath had cleared the terrain 
immediately ahead of the aircraft by less than 5 deg of overshoot. This flightpath-based criterion was 
applicable to the F-16 since it only used straight flyup maneuvers, and the aircraft was usually near 
wings-level when it cleared significant terrain features. It now appears that the production F-16 version of 
Auto GCAS will be able to meet that criterion, and related F-16 pilot comments have been very favorable. 
However, a similar criterion does not yet exist for the timely termination of UAV avoidance maneuvers. 

Recommendation 14 (R14): Future Auto GCAS projects on UAVs should develop a termination 
timeliness criterion specific to that project. 

The SUAV Auto GCAS mechanization added another dimension to a termination assessment because 
of the options for turning avoidance maneuvers. Since most of the SUAV avoidances were turning 
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maneuvers, the most relevant angular measure was heading change. In addition, UAV pilots may be able 
to tolerate more angular termination overshoot in terms of heading change than F-16 pilots in terms of 
flightpath angle. 

A termination analysis was accomplished for every run that continued all the way through normal 
termination (without the safety pilot taking control). Of the 52 valid initiations, 28 continued all the way 
through normal termination without being interrupted by the safety pilot or experiencing telemetry dropout. 
On each run, an ideal termination heading was calculated using a simple extrapolation of the tangent line 
at each point along the turning avoidance maneuver. The ideal heading was defined as the point at which 
that tangent line first became clear of terrain. That ideal heading calculation included three frames of 
persistence, for consistency with the on-board termination calculation. The ideal heading was compared 
with the actual heading at termination to obtain a delta heading. 

The specific methodology is described in appendix B and an example is shown in figure 48. The 
semi -horizontal black and red lines show the trajectory of the test aircraft prior to and after the avoidance 
maneuver initiation, respectively. The vertical black and red lines show the update rate at which the 
algorithm was calculated in that segment. The green lines show tangential extrapolations at key points along 
the trajectory. Those extrapolations included a vertical component that was based on the climb rate at that 
point. This example shows how straight tangent lines were projected from the turning maneuver trajectory 
until all terrain within approximately 3 nm was cleared for three sequential frames. The distance of 3 nm 
was selected to be consistent with the normal Auto GCAS algorithm, but could be tuned for specific 
platforms. The projected tangent lines slope up in order to include the climb rate established at that point 
in the avoidance maneuver. 



Maneuver trajectory 
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Figure 48. Ideal termination heading. 

Despite the lack of a formally-developed termination criterion for UAVs, a reference of some kind 
was still needed to help interpret the test results. It was assumed that a UAV pilot would tolerate quite a bit 
more angular overshoot than the 5-deg flightpath overshoot that worked well for the F-16 pilots. Therefore 
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a “Good” termination was defined to be no sooner than the ideal heading, but less than 15 deg past that 
ideal heading. The results are shown in figure 49. 
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Figure 49. Termination timeliness: heading. 

The data in figure 49 show that there was only one avoidance maneuver that would have been 
considered “Good” using the 0- to 15-deg delta heading criteria. The remaining maneuvers were 
considerably late or early. This undesirable result can be attributed to the way in which the P-factor effect 
was used as part of the termination logic. 


When the DROID P-factor effect was initially quantified, the decision was made to incorporate that 
characteristic as part of the trajectory prediction algorithm instead of taking the extra time to try to design 
a set of autopilot commands to compensate for the P-factor effect. This approach also influenced the 
termination logic because the straight trajectory (which is a curving trajectory due to the P-factor effect) 
was used to determine when the aircraft was clear of terrain. 


An example of how the P-factor effect induced late terminations is shown in figure 50. The 
semi -horizontal black and red lines show the trajectory of the test aircraft prior to and after the initiation of 
the avoidance maneuver (as in figure 48). The green line shows the tangential extrapolation of the ideal 
termination (three sequential frames clear of terrain). The transition from the red line to the blue line shows 
the point at which the flight-test maneuver was terminated. The blue line represents the straight trajectory 
(as influenced by the P-factor effect) that was used by the Auto GCAS algorithm to determine when the 
avoidance was terminated. Even though the ideal green tangent line for this maneuver was clear of both the 
near ridgeline and the more distant peaks, that maneuver did not terminate until the blue straight trajectory 
(as influenced by the P-factor effect) was clear of the terrain. The specific features of the terrain in the test 
area tended to amplify this effect, but the overall result tended to be a significant delay in termination that 
would most likely be considered a nuisance, the maneuver lasting much longer than necessary. 
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Flight 21 event 4 



“Straight” trajectory 
(influenced by P-factor) 


Figure 50. Late termination example. 


An example of how the P-factor effect induced early terminations is shown in figure 51. The 
semi-horizontal red line shows the trajectory of the test aircraft during the avoidance maneuver. 
The transition from the red line to the blue line shows the point at which the flight-test maneuver was 
terminated. The orange line shows the tangential extrapolation of the trajectory at that point. The green line 
shows the tangential extrapolation of the ideal termination (three sequential frames clear of terrain). In this 
case, the blue curving trajectory (as influenced by the P-factor effect) caused the termination logic to see 
the gap in terrain before the aircraft was pointed toward that gap, causing the avoidance maneuver to 
terminate while the aircraft was still pointed at terrain (orange line). In several cases the aircraft did not 
continue in the turn, which triggered the almost-immediate initiation of additional avoidance maneuvers. 
Although not a direct safety hazard, when additional avoidance maneuvers occur immediately after a 
previous avoidance maneuver has terminated, the result creates an impression of reduced confidence in the 
Auto GCAS algorithm, and would probably be considered a nuisance as compared to a single, longer 
avoidance maneuver. 


Flight 19 event 16 
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Figure 5 1 . Early termination example. 
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Given the overall undesirable results, it may not be warranted to include the P-factor effect in the 
termination logic even if the P-factor effect is considered in the development of the trajectory prediction. 
This rationale is based on the principle that an aircraft should be considered clear of terrain when it can roll 
out of the turn and continue in a straight climb without intersecting the digital terrain. 

Recommendation 15 (R15): Future Auto GCAS projects on propeller aircraft should determine 
if the use of the P-factor effect in the termination logic is warranted on that platform. 

Direct pilot evaluations of the termination characteristics were not obtained because nuisance 
evaluations were only accomplished on two flights and no avoidance maneuvers were initiated when the 
Multi-Trajectory option was set to ON. In addition, the ground control van mechanization did not return 
control directly to the pilot, so any qualitative termination evaluation would have been skewed when 
compared to a more representative mechanization. Pilots flew some of the collision avoidance test points, 
but the focus was on getting the system to function as desired, and not on a thorough evaluation of 
termination timeliness. 


Termination timeliness was analyzed in terms of delta time in addition to the delta heading analysis. 
A “Good” termination was defined to be no earlier than the time at which the ideal heading was achieved, 
and less than 1.5 s beyond that time (1.5 s correlates to the 15-deg delta heading based on a nominal turn 
rate of 10 deg/s during these avoidance maneuvers). The results are shown in figure 52. 
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Figure 52. Termination timeliness: time. 

Using the delta time criterion also results in a single maneuver that would have been considered 
“Good.” The remaining maneuvers reflect the undesirable effects of the P-factor. The data depicted in figure 
52 indicate that termination timeliness was generally between 1-5 s early for left turns, and 1-5 s late for 
right turns. Two outliers are shown terminating early by approximately 8 and 10 s. These two outliers show 
that the method for calculating the ideal heading may be susceptible to using instantaneous values for the 
extrapolated flightpath. Future projects implementing similar analysis techniques should consider using a 
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five-point moving average instead of the instantaneous values (which may be more susceptible to gusting 
winds). 

The overall conclusion from this termination analysis is that the designers for each platform will need 
to carefully consider the logic to be used for when an avoidance maneuver should be terminated and control 
returned to the pilot. 

Recommendation 16 (R16): Future Auto GCAS projects should consider implementing 
termination logic that returns control to the pilot when well clear of terrain in the immediate vicinity, 
but should not be overly conservative for distant peaks. 

Trajectory Prediction Accuracy 

The accuracy of the trajectory prediction can be assessed by answering two fundamental questions: 

• How well did the trajectory prediction at initiation compare to the flightpath of the actual avoidance 
maneuver? 

• Did the flightpath of the actual avoidance maneuver stay within the scan pattern used at initiation? 

These questions are addressed by utilizing the analyzed data from individual test runs as in the example 
in figure 53 to create the summary data that are depicted in figure 54. A more complete description of the 
technique that was used is presented in appendix B. 
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Figure 53. Worst-case trajectory example. 
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Figure 54. Trajectory prediction accuracy. 


Figure 53 shows the worst-case example from all test runs. On this run (flight 18, event 6) the actual 
flightpath went the furthest outside of the scan pattern on the side closest to terrain. The blue line shows the 
trajectory prediction at initiation. The green circles show the scan pattern at initiation, with the dashed white 
line representing the outer edges of that scan pattern. The red line shows the actual flightpath during the 
avoidance maneuver. The yellow dot identifies the point where the actual flightpath went the furthest 
outside the scan pattern. 

The situation shown in figure 53 is undesirable because the aircraft could have flown close to terrain 
features that might not have been detected by the scan pattern. In this case, the resulting minimum AGL 
was 125 ft, but that test point had been executed with the TCB set to 100 ft. If the TCB had been set to zero, 
terrain clearance would have been approximately 25 ft. This was the lowest minimum AGL for any test 
run, and it was considerably lower than the more typical clearance at 100 ft or greater. 

In a production Auto GCAS implementation this characteristic could degrade CFIT protection. Limited 
analysis indicates that this worst-case example was probably induced by changing winds during the 
avoidance maneuver. The onboard wind calculations from the Piccolo II autopilot showed a significant shift 
in wind magnitude and direction during the maneuver. However, those onboard wind calculations become 
more suspect when the aircraft is not in straight -and-level flight. If confirmed, this characteristic warrants 
additional effort to account for changing winds through increased buffers, a wider scan pattern, or some 
other method. 

Recommendation 17 (R17): Future Auto GCAS projects should determine if changing winds 
during the recovery should be addressed in the design for that platform. 

A case-by-case analysis of each test run is useful, but it is even more helpful to look at summary data 
that encompass all of the relevant test results. The individual run analysis technique presented in figure 53 
was applied to all relevant test runs to obtain the summary data depicted in figure 54. Each symbol in 
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figure 54 represents a single test run at the point along the actual flightpath that was furthest away from the 
trajectory prediction. 

Although the scan pattern size and shape varied based on airspeed, wind, and other factors, the data 
were normalized to a generic scan pattern by using a percentage deviation from the centerline trajectory 
prediction. At any given distance along the centerline, 100 percent was located on the scan pattern line 
(perpendicular to the centerline) and 50 percent was located halfway between the centerline and the scan 
pattern line. 

The normalized data depicted by figure 54 also include test runs that resulted in right avoidance 
maneuvers (shown with closed symbols) even though the generic scan pattern shown is for left maneuvers 
(shown with open symbols). The data for right maneuvers was included by flipping the x-axis for those test 
runs. This method maintained the relative position of each dot in the sense that any symbols below the 
centerline in figure 54 were inside the turn, whereas any symbols above the centerline were outside the 
turn. The specific normalization analysis techniques are described in appendix B. 

Figure 54 addresses the two fundamental questions about the accuracy of the trajectory prediction. The 
summary data given in figure 54 show that most of the test runs flew reasonably close to the centerline of 
the trajectory prediction, and most of the worst-case locations were within the scan pattern. Another way 
of showing the same trend is presented in figure 55. 
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Figure 55. Trajectory prediction histogram: across the scan pattern. 

Figure 55 shows the same data from figure 54 represented by a histogram indicating the worst-case 
position as a percentage of the scan width relative to the centerline. Almost half of the worst-case positions 
were less than 40 percent of the scan pattern width. Most runs stayed with the scan pattern for the entire 
avoidance maneuver. Only a few runs strayed outside the scan pattern (as indicated on the histogram for 
values greater than 100 percent). 
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Only one case went beyond the scan pattern on the outside of the turn (closer to terrain). That run was 
at 132 percent relative to the outer scan pattern line and occurred during event 6 of flight 18 (fig. 53). 

Three cases went beyond the scan pattern on the inside of the turn (farther from terrain). These three 
runs ranged from 1 17 percent to 197 percent relative to the inner scan pattern line. Similar to event 6 of 
flight 18, it is suspected that variable winds during these maneuvers contributed to flying beyond the scan 
pattern. These cases do not necessarily indicate degraded CFIT protection, but there could be increased 
nuisance potential if this situation is not adequately addressed in a production implementation. The only 
situation in which these three cases might result in degraded CFIT protection would be if the aircraft were 
descending into terrain that happened to enter the scan pattern inside of the predicted avoidance maneuver 
(at the same time as when the other avoidance directions were unavailable). That situation may be possible 
but is probably unlikely. 


Figure 56 shows the same data from figure 54, represented by a histogram indicating where the 
worst-case locations occurred relative to the distance (range from initiation) along the centerline. This 
histogram shows that most of the worst-case locations were within the first third of the total scan length. 
The same trend can be seen in figure 54. This does not imply that the scan length was longer than necessary. 
The avoidance maneuvers for these particular test situations were completed relatively quickly, and 
therefore any trajectory errors did not have time to grow larger. Different test situations could lead to 
trajectories that last longer and therefore require the longer scan length. 
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Figure 56. Trajectory prediction histogram: along the centerline. 

Scan Pattern Functionality 

The functionality of the scan pattern can be assessed by answering two fundamental questions: 

• 1 . What was the location of the terrain post that triggered the avoidance maneuver (relative to the 

scan pattern)? 
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• 2. Did the flightpath of the actual avoidance maneuver stay within the scan pattern used at 

initiation? (Note: this is the same question that was used to assess the trajectory prediction 
accuracy; the trajectory prediction accuracy and scan pattern functionality modular components are 
inter-related.) 

These questions are addressed by utilizing the analyzed data from individual test runs similar to the 
example presented in figure 57 to create the summary data that are depicted in figure 58. The individual 
run in figure 57 is the same run that was shown in figure 53. Additional data is presented in figure 54. 
The terrain post that triggered the avoidance maneuver is represented by the orange balloon in figure 57. 
The method used to determine the specific location of that trigger post for a particular run is described in 
appendix B. In the SUAV Auto GCAS algorithm, the terrain posts were not used directly, but rectangular 
areas around each post were created at the same height as that post. The rectangular area is represented by 
the orange box in figure 57. 
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Figure 57. Scan pattern functionality. 

An avoidance maneuver was triggered as soon as one of the rectangular terrain polygons was within 
one of the green scanning circles at a height above the trajectory prediction (including any built-in or 
flight-test altitude buffers added to the terrain height). 

In figure 57 the orange terrain polygon was within three of the green scan circles. In this case, the 
buffered terrain height was above the trajectory prediction at all three of those scan circles, so the avoidance 
maneuver was triggered by whichever was first in the internal sequence of checks. One frame earlier 
(approximately one -fifth of one second), the path of the trajectory prediction was far enough away from 
that particular terrain polygon/post so that an avoidance maneuver was not triggered. 

The main point to be gleaned from figure 57 is that the individual terrain post that triggered this flyup 
maneuver was outside the scan pattern. As will be seen in figure 58, this result was fairly common, and the 
terrain scanning approach was implemented as a conscious part of the design process to ensure that terrain 
posts were not missed. 

The summary data presented in figure 58 were constructed using the same type of normalization process 
as applied to those data depicted in figure 54. As can be seen, almost all of the trigger posts were outside 
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the scan pattern (on the side closer to terrain). A small number of trigger posts were within the scan pattern, 
and one was outside the scan pattern on the inner side of the turn. These occurrences were generally when 
the test aircraft was in a dive, so that the scan pattern or trajectory prediction descended down onto the 
highest terrain post, as compared to the more typical case in which the test aircraft flew in level flight 
toward the trigger post. 
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Figure 58. Trigger post locations. 


The mean for trigger post locations was at 175 percent relative to the scan width for the outer scan line. 
The trigger posts were usually outside the scan pattern because of the scan technique that included any 
portion of a terrain rectangle within the scan pattern (fig. 28). There was no significant difference in trigger 
post location for left or right avoidance maneuvers. 

The trigger post with the greatest percentage outside the scan pattern was at 366 percent relative to the 
scan width for the inner scan line. That seemingly extreme case was from event 5 of flight 18, which was a 
straight activation from a diving maneuver over smooth terrain. That straight activation reflected the general 
trend expected from diving maneuvers over smooth terrain: the straight trajectory prediction climbs at 
1000 fpm whereas the left and right predictions climb at 800 fpm. Over smooth terrain the left and right 
trajectories will be lower and intersect with smooth digital terrain before the straight trajectory, resulting in 
a straight trajectory as the last viable option. 

In addition, the same trend resulted in trigger posts quite close to the initiation point because the straight 
trajectory prediction curved upwards quite rapidly compared to the essentially flat digital terrain. When the 
trigger post occurred close to the initiation, the very narrow scan pattern detected the tiny corner of a terrain 
rectangle generated from a post that was well outside the scan pattern compared to the scan width. 

Figure 59 shows the same data from figure 58, represented by a histogram indicating the trigger post 
locations as a percentage of the scan width relative to the centerline. The data in figure 59 resulted in a 
mean value of 175 percent scan width and a standard deviation of 71 percent. The straight activation at 
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366 percent was an outlier and was not included in this histogram, but the value was included in the 
calculation of the mean. 
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Figure 59. Trigger post location histogram: across the scan pattern. 
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Figure 60. Trigger post location histogram: along the centerline. 
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Figure 60 shows the same data from figure 58, represented by a histogram indicating the worst-case 
locations relative to the distance (range from initiation) along the centerline. The data in figure 60 resulted 
in a mean value of 38 percent range along the centerline and a standard deviation of 17 percent. 

Avoidance Maneuver Summary 

This section describes the general characteristics of the avoidance maneuvers encountered during this 
project. The discussion includes the flight conditions at initiation, the direction in which the algorithm 
commanded the maneuver, and the overall duration of the maneuver (in terms of time and heading change). 

The basic flight conditions at initiation are shown in figures 61 and 62. Figure 61 shows that the DROID 
speed range of 40 to 80 KIAS was well-covered by test conditions. There were two main target airspeeds 
on the test cards: 45 and 70 KIAS. However, the normal variations induced by autopilot control and piloted 
maneuvering provided the additional spread around the two main airspeeds. Most of the initiations were in 
relatively level flight, but a few shallow dives and climbs were also accomplished. The mishap cases that 
were replicated tended to be at the higher end of the DROID speed range, because those mishaps occurred 
on the MQ-1 and the MQ-9. 
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Figure 6 1 . Initiation flightpath versus airspeed. 
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Figure 62. Initiation flightpath versus bank angle. 

Figure 62 shows the bank angle variations at initiation. Most of the runs were near wings-level, but a 
few were initiated at approximately 30-40 deg bank. The three mishap cases targeted 0 deg, 15 deg, and 
25 deg of bank. Although one test card sequence targeted negative bank angle, that series was only 
attempted on flight 17 and the resulting data were not usable due to poor telemetry on that flight. 

Almost all of the avoidance maneuvers were to the left or the right, as shown in figure 63. The data in 
figure 63 include all valid initiations, even if the safety pilot took control later. 
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Figure 63. Avoidance maneuver direction. 
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Only two test setups resulted in straight avoidance maneuvers with usable data. Straight avoidance 
maneuvers were only expected to occur over smooth terrain, or possibly during ridge crossings. A number 
of smooth-terrain test points were attempted, but most of those occurred on missions with poor telemetry 
and resulted in unusable data. The Auto GCAS algorithm initiated one straight avoidance maneuver during 
a ridge crossing on flight 20, but the Gumstix® personal computer was not set up correctly on that mission 
and the autopilot did not respond to the commanded maneuver. 


The longest avoidance maneuver was approximately 15 s and the shortest approximately 1 s, as shown 
in figure 64. The duration was a simple calculation that began when the Auto GCAS algorithm initiated the 
avoidance maneuver and ended when the algorithm determined the maneuver was complete. The data in 
figure 64 do not include runs in which the safety pilot took control prior to normal termination. 


Avoidance duration, time 



Figure 64. Avoidance maneuver duration. 

There was considerable variation in avoidance maneuver duration with no discernible pattern. This 
variation was not surprising, because the duration was solely driven by the amount of time needed for the 
aircraft to clear the terrain. Many of the test setups were intentionally targeted at a bowl-shaped canyon in 
order to stress the system. That bowl-shaped canyon tended to force the aircraft to “go back toward the way 
it had come,” resulting in quite a few avoidance maneuvers each lasting longer than 10 s. The duration of 
avoidance maneuvers was also influenced by the way the P-factor effect was modeled in the termination 
logic. 


The amount of heading change that occurred during avoidance maneuvers is shown in figure 65. The 
data in figure 65 only include turning maneuvers, and only include runs that continued to normal 
termination before the safety pilot took control. 
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Figure 65. Avoidance maneuver heading change. 

The effect of the P-factor bias can be seen in figure 65. Left turns had a mean heading change of 
approximately 80 deg, whereas right turns had a mean heading change of approximately 110 deg. Left turns 
tended to have less heading change and right turns more heading change. It was not unusual for avoidance 
maneuvers to continue for 90 deg heading change or more. 


Concluding Remarks 


The small unmanned aerial vehicle (SUAV) Automatic Ground Collision Avoidance System (GCAS) 
project successfully demonstrated many important collision avoidance technologies. Foremost among these 
demonstrations were: 

• Auto GCAS testing with multiple avoidance maneuvers including turns to either side; 

• Testing of digital terrain scanning techniques determined directly from the predicted trajectory; 

• In-flight testing of highly compressed digital elevation models; 

• In-flight testing of digital elevation models that had been customized to reflect tighter tolerances in 
some areas and relaxed tolerances in other areas; 

• In-flight testing of Auto GCAS on an unmanned aerial vehicle; and 

• Hosting Auto GCAS algorithms on a smartphone during flight tests. 

Additional noteworthy accomplishments included: 

• Design and implementation of a flight-test user interface that enabled ground operators to control 
the Auto GCAS algorithms on the smartphone (either with the smartphone on the ground or on 
board the test aircraft); 

• Rapid design and implementation of a directional antenna system to avoid multi-path noise when 
in the vicinity of terrain, which greatly improved communications between the test aircraft and the 
ground control van; 
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• Derivation of Dry den Remotely Operated Integrated Drone trajectory prediction models purely 
from very limited flight-testing of the specific avoidance maneuvers on the test aircraft, without 
relying on any type of simulation; 

• Innovative use of Google Earth to enable pre -flight visualizations of Auto GCAS setups, enhance 
test-card generation, and greatly improve post-flight data analysis of test maneuvers; and 

• Auto GCAS algorithms coded into Java™ (Oracle Coiporation, Redwood Shores, California) (the 
native language for the smartphone). 

Although the SUAV Auto GCAS implementation was not intended for production, the test results are 
positive enough to provide a solid basis for scaling onto many production UAV platforms. The same basic 
SUAV Auto GCAS concepts should also be adaptable to similar aircraft types having relatively low 
airspeeds and low maneuverability (typical of general aviation). 

Some of the concepts have demonstrated the potential to provide significant capabilities for Auto GCAS 
implementations on higher-airspeed, higher-maneuverability aircraft such as fighters, transports, business 
jets, and airliners. These concepts include the use of highly-compressed DEMs, multi-trajectory avoidance 
options, and terrain scanning techniques. 

Auto GCAS follow-on projects could include: 

• Implementation of GCAS algorithms on a smartphone or tablet for general aviation platforms. 
General aviation applications could be automated when a digital autopilot is available, but 
significant improvements to protection against controlled flight into terrain (CFIT) might also be 
obtained when a digital autopilot is not available by using the same GCAS algorithms as part of a 
ground proximity warning system utilizing manual pilot reactions. Any automatic implementation 
of GCAS using a smartphone or tablet would need to pay particular attention to the redundancy 
and reliability aspects in order to avoid violation of the “do no harm” principle. General aviation 
smartphone or tablet implementations should be evaluated first in a simulation environment and 
then in flight-testing. 

• Flight-test demonstration of GCAS algorithms for helicopter platforms. It is expected that 
helicopters could also benefit from automatic GCAS or a GCAS-based ground proximity warning 
system. Because of the additional avoidance maneuver options available to a helicopter (stop and 
hover, reverse direction, et cetera) additional development would be required to properly evaluate 
GCAS tradeoffs. 

• Analytical studies and flight-test demonstrations to evaluate the effectiveness of new Auto GCAS 
concepts for fighter platforms. Even though a very capable production version of Auto GCAS is 
nearing deployment to the F-16 fleet, variations of Auto GCAS are still in development for the 
F-22 and F-35. Some of the techniques implemented on the SUAV Auto GCAS could provide 
significant improvements to the tradeoff between CFIT protection and nuisance potential for any 
of those airplanes. 

• Analytical studies and flight-test demonstrations to evaluate the effectiveness of new Auto GCAS 
concepts for transport platforms. Transport platforms have limited maneuverability compared to 
fighter platforms, but also have much higher airspeed envelopes compared to an SUAV. This 
characteristic might lead to the need for adaptations of existing GCAS technologies that would be 
appropriate to explore in a flight -test development environment. 
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Summary of Recommendations 


Recommendation 1 (Rl): Future Auto GCAS projects should consider applying resources to 
develop improved integration of in-flight wind estimates with the Auto GCAS algorithm (page 19). 

Recommendation 2 (R2): Future Auto GCAS projects should consider implementing a monitor 
to isolate and protect against corrupted digital terrain data (page 26). 

Recommendation 3 (R3): Future Auto GCAS projects should consider implementing a monitor 
to protect against false requests for avoidance maneuvers (page 26). 

Recommendation 4 (R4): Future Auto GCAS projects should pay special attention to the input 
signal conditioning necessary for that particular implementation (page 28). 

Recommendation 5 (R5): Future Auto GCAS projects should consider incorporating multiple 
trajectory predictions to provide more than one option and to reduce nuisance potential (page 30). 

Recommendation 6 (R6): Future Auto GCAS projects for performance-limited aircraft may need 
to consider including density altitude as an input to the trajectory prediction (page 36). 

Recommendation 7 (R7): The developers on any Auto GCAS project should consider the addition 
of vertical obstructions as part of the algorithm (page 39). 

Recommendation 8 (R8): Future Auto GCAS projects should carefully assess the tradeoffs 
between short-term PVI cost savings against the potential for longer-term impacts on the user 
(page 49). 

Recommendation 9 (R9): Future Auto GCAS projects involving flight-testing of UAVs should 
pay particular attention to telemetry and control links when operating in close proximity to terrain 
(page 49). 

Recommendation 10 (RIO): Future Auto GCAS projects on UAVs should consider a mode state 
implementation that allows the avoidance to continue even after reaching a FAIL state 
(page 50). 

Recommendation 11 (Rll): Future Auto GCAS projects on UAVs should consider a 
self-recovering mode state implementation to resume CFIT protection as soon as the cause for the 
FAIL state no longer exists (page 50). 

Recommendation 12 (R12): Future Auto GCAS test projects using a smartphone as the data 
recording device should consider implementing a recording method that provides data throughout 
the flight, not just when avoidance maneuvers occur (page 67). 

Recommendation 13 (R13): Future Auto GCAS projects on UAVs should develop a nuisance 
criterion specific to that project (page 71). 

Recommendation 14 (R14): Future Auto GCAS projects on UAVs should develop a termination 
timeliness criterion specific to that project (page 74). 
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Recommendation 15 (R15): Future Auto GCAS projects on propeller aircraft should determine 
if the use of the P-factor effect in the termination logic is warranted on that platform 
(page 78). 

Recommendation 16 (R16): Future Auto GCAS projects should consider implementing 
termination logic that returns control to the pilot when well clear of terrain in the immediate vicinity, 
but should not be overly conservative for distant peaks (page 79). 

Recommendation 17 (R17): Future Auto GCAS projects should determine if changing winds 
during the recovery should be addressed in the design for that platform (page 80). 
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Appendix A: Parameter List 


The main purpose in presenting the parameter list is to provide future project teams with a stalling point 
for consideration when they are developing their own project-specific parameter list. Table A1 provides a 
complete list of the parameters that were available to the Auto GCAS test team. All of the parameters that 
were used for post-flight analysis were recorded on the smartphone and downloaded after the flight. The 
post -flight analysis parameters were recorded on the smartphone regardless of its location (whether in the 
ground control van or in the DROID). Additional telemetered data were available in the ground control van, 
but those data were not used for post-flight analyses and so are not included in table Al. Additional data 
were also recorded on the user interface (UI) laptop computer, but those data were not used for post-flight 
analyses and so have not been included in table Al . 

Three sources provided the data that were recorded on the smartphone: the Piccolo 11 autopilot; the 
UI laptop computer (by way of uplinked telemetry or the Gumstix® personal computer); and the Auto GCAS 
algorithm on the smartphone. Selected parameters from the Piccolo 11 autopilot included basic aircraft state 
information such as latitude, longitude, airspeed, altitude, angular rates, linear accelerations, et cetera, along 
with autopilot status and target values and the winds as estimated by the standard Piccolo II autopilot 
software. The UI parameters consisted primarily of state values that could be set by the UI Operator: Terrain 
Clearance Buffer; horizontal and vertical uncertainties (for the built-in buffers); the flag to switch between 
multiple avoidance trajectories and the straight-only trajectory, and others. The data from the Auto GCAS 
algorithm on the smartphone included Auto GCAS modes, time to flyup for each of the three trajectories, 
and minimum approach to terrain for each of the three trajectories, along with some Auto GCAS status 
words. 

A number of parameters were not directly available from any of the sources but could be calculated 
using the available parameters. Those calculated parameters are listed near the end of table Al . 

The parameter names in table Al are listed in two columns: “Smartphone parameters,” and 
“AUTO GCAS maneuver-specific parameters.” Most of the parameter names are the same in both of these 
columns. In a few cases the parameter existed in only one form, indicated in table Al by the entry “N/A.” 
in the relevant parameter column. The difference only applied to the type of post-flight analysis being 
conducted. 

Table Al . Small Unmanned Aerial Vehicle Automatic Ground Control Avoidance System parameters. 


Smartphone parameters 

AUTO GCAS 

maneuver-specific parameters 

Units 

Description 

Source 

Data 

rate 

time_system 

time_system 

ms 

Time since start-up 

Piccolo II 

5 Hz 

fit 

N/A 

N/A 

Flight number 

Algorithm 

5 Hz 

exe 

exe 

N/A 

Execute flag (1 or 0) 

Smartphone 

5 Hz 

latitude 

latitude 

deg 

GPS latitude 

Piccolo II 

5 Hz 

longitude 

longitude 

deg 

GPS longitude 

Piccolo II 

5 Hz 

altitude_gps_wgs84 

altitude_gps_wgs84 

ft 

GPS altitude above the 
WGS84 ellipsoid 

Piccolo II 

5 Hz 

ktas 

ktas 

kn 

Calculated true airspeed 

Piccolo II 

5 Hz 

kias 

kias 

kn 

Indicated airspeed (raw) 

Piccolo II 

5 Hz 

bankAngle 

bankAngle 

deg 

Bank (roll) angle 

Piccolo II 

5 Hz 

climbRate 

climbRate 

ft/s 

Climb rate 

Piccolo II 

5 Hz 

rollRate 

rollRate 

deg/s 

Roll rate, as read from 
Piccolo II 3 -axis 
gyroscope 

Piccolo II 

5 Hz 

heading 

heading 

deg 

True heading 

Piccolo II 

5 Hz 


93 





windVelNorth 

windVelNorth 

ft/s 

Wind velocity, north 
(parameter is positive with 
wind from south) 

Piccolo II 

5 Hz 

windVelEast 

windVelEast 

ft/s 

Wind velocity, east 
(parameter is positive with 
wind from west) 

Piccolo II 

5 Hz 

horizUncertainty 

horizUncertainty 

ft 

Horizontal uncertainty 

UI laptop 

5 Hz 

vertUncertainty 

vertUncertainty 

ft 

Vertical uncertainty 

UI laptop 

5 Hz 

TCB 

TCB 

ft 

Terrain Clearance Buffer 

UI laptop 

5 Hz 

rollRateLag 

rollRateLag 

N/A 

Roll rate lag 

UI laptop 

5 Hz 

airspeedLag 

airspeedLag 

N/A 

Airspeed lag 

UI laptop 

5 Hz 

climbRateLag 

climbRateLag 

N/A 

Climb rate lag 

UI laptop 

5 Hz 

multiAvoidReq 

multiAvoidReq 

N/A 

Multi-avoid request 

UI laptop 

5 Hz 

acDataValid 

acDataValid 

N/A 

AC data valid flag 

UI laptop 

5 Hz 

AGC AS modeReq 

AGC AS modeReq 

N/A 

AGCAS mode request 

UI laptop 

5 Hz 

AGCASmode 

AGCASmode 

N/A 

AGCAS mode as reported 
by smartphone 

Algorithm 

5 Hz 

apCmd 

apCmd 

N/A 

AGCAS autopilot 
command request 

Smartphone 

5 Hz 

strTime2Flyup 

strTime2Flyup 

s 

AGCAS time to flyup, 
straight 

Smartphone 

5 Hz 

leftTime2Flyup 

leftTime2Flyup 

s 

AGCAS time to flyup, left 

Smartphone 

5 Hz 

rightTime2Flyup 

rightTime2Flyup 

s 

AGCAS time to flyup, 
right 

Smartphone 

5 Hz 

minApprTenainStr 

minApprTenainStr 

ft 

AGCAS Minimum 
Approach to Terrain, 
straight 

Smartphone 

5 Hz 

minApprTenainLeft 

minApprTenainLeft 

ft 

AGCAS Minimum 
Approach to Terrain, left 

Smartphone 

5 Hz 

minApprTerrainRight 

minApprTerrainRight 

ft 

AGCAS Minimum 
Approach to Terrain, right 

Smartphone 

5 Hz 

errorCode 

errorCode 

N/A 

AGCAS error code 

Algorithm 

5 Hz 

warningCode 

warningCode 

N/A 

AGCAS warning code 

Smartphone 

5 Hz 

infoCode 

infoCode 

N/A 

AGCAS info code 

Smartphone 

5 Hz 

lmRefLatitude 

lmRefLatitude 

deg 

Local map reference, 
latitude 

Smartphone 

5 Hz 

ImRefLongitude 

ImRefLongitude 

deg 

Local map reference, 
longitude 

Smartphone 

5 Hz 

time_gps_hours 

time_gps_hours 

hr 

GPS time 

Piccolo II 

5 Hz 

time_gps_minutes 

time_gps_minutes 

min 

GPS time 

Piccolo II 

5 Hz 

time_gps_seconds 

time_gps_seconds 

s 

GPS time 

Piccolo II 

5 Hz 

altitude_baro 

altitude_baro 

ft 

Barometric altitude, MSL 

Piccolo II 

5 Hz 

laserAlt 

laserAlt 

ft 

Laser altitude, AGL 

Piccolo II 

5 Hz 

RPM 

RPM 

rpm 

Revolutions per minute 

Piccolo II 

5 Hz 

mag_hdg_deg 

mag_hdg_deg 

deg 

Magnetic heading 

Piccolo II 

5 Hz 

pitch_deg 

pitch_deg 

deg 

Pitch 

Piccolo II 

5 Hz 

yaw_deg 

yaw_deg 

deg 

Yaw 

Piccolo II 

5 Hz 

pitch_rate_dps 

pitch_rate_dps 

deg/s 

Pitch rate 

Piccolo II 

5 Hz 

yaw_rate_dps 

yaw_rate_dps 

deg/s 

Yaw rate 

Piccolo II 

5 Hz 

xaccel_g 

xaccel_g 

g 

Acceleration, x-direction 

Piccolo II 

5 Hz 

yaccel_g 

yaccel_g 

g 

Acceleration, y-direction 

Piccolo II 

5 Hz 

zaccel_g 

zaccel_g 

g 

Acceleration, z-direction 

Piccolo II 

5 Hz 

LoopT argetO_kts 

LoopT argetO_kts 

kn 

Indicated airspeed loop 
target 

Piccolo II 

5 Hz 

LoopTargetl_ft 

LoopTargetl_ft 

ft 

Altitude loop target 

Piccolo II 

5 Hz 

LoopT arget2_deg 

LoopT arget2_deg 

deg 

Bank loop target 

Piccolo II 

5 Hz 

LoopTarget3_deg 

LoopTarget3_deg 

deg 

Flaps loop target 

Piccolo II 

5 Hz 

LoopT arget4_deg 

LoopT arget4_deg 

deg 

Heading loop target 

Piccolo II 

5 Hz 

LoopTarget5_deg 

LoopTarget5_fpm 

ft/rnin 

VRate loop target 

Piccolo II 

5 Hz 
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AP_Global 

AP_Global 

N/A 

Autopilot global on/off 
flag. Indicates whether or 
not SUAV was flown by 
ground control 
operator(s), or whether or 
not a safety pilot had 
control. 

Piccolo II 

5 Hz 

TrackerStatus 

TrackerStatus 

N/A 

Tracker status 

Piccolo II 

5 Hz 

LoopStatusO 

LoopStatusO 

N/A 

Indicated airspeed loop 
status 

Piccolo II 

5 Hz 

LoopStatusl 

LoopStatusl 

N/A 

Altitude loop status 

Piccolo II 

5 Hz 

LoopStatus2 

LoopStatus2 

N/A 

Bank loop status 

Piccolo II 

5 Hz 

LoopStatus3 

LoopStatus3 

N/A 

Flaps loop status 

Piccolo II 

5 Hz 

LoopStatus4 

LoopStatus4 

N/A 

Heading loop status 

Piccolo II 

5 Hz 

LoopStatus5 

LoopStatus5 

N/A 

VRate loop status 

Piccolo II 

5 Hz 

windVelNAve 

windVelNAve 

ft/s 

10 s average of parameter 
windVelNorth 

UI laptop 

5 Hz 

windVElEAve 

windVelEAve 

ft/s 

10 s average of parameter 
windVelEast 

UI laptop 

5 Hz 

triggerPressed 

triggerPressed 

N/A 

Trigger pressed 

UI laptop 

5 Hz 

PARS state 

PARS state 

N/A 

Pilot Activated Recovery 
Switch state 

UI laptop 

5 Hz 

PARSengaged 

PARSengaged 

N/A 

Pilot Activated Recovery 
Switch engaged flag 

UI laptop 

5 Hz 

flyupActive 

flyupActive 

N/A 

Flyup active flag. Boolean 
1 (flyup active) or 0 (flyup 
not active). Same as 
parameter flyup_active. 

UI laptop 

5 Hz 

noTMcount 

noTMcount 

N/A 

Telemetry failure flag 

Smartphone 

5 Hz 

flyupHold 

flyupHold 

N/A 

Flyup hold flag 

Smartphone 

5 Hz 

flyupHoldCount 

flyupHoldCount 

N/A 

Flyup hold count 

Smartphone 

5 Hz 

Vnorth 

N/A 

ft/s 

North velocity (north-east- 
down frame) 

Piccolo II 

5 Hz 

Veast 

N/A 

ft/s 

East velocity (north-east- 
down frame) 

Piccolo II 

5 Hz 

Vdown 

N/A 

ft/s 

Down velocity (north- 
east-down frame) 

Piccolo II 

5 Hz 

Clock_ms 

Clock_ms 

ms 

Same as parameter 
time_system 

Calculated 

N/A 

Hours 

Hours 

hr 

Same as parameter 

time_gps_hcmrs 

Calculated 

N/A 

Minutes 

Minutes 

min 

Same as parameter 
time_gps_minutes 

Calculated 

N/A 

Seconds 

Seconds 

s 

Same as parameter 
time_gps_seconds 

Calculated 

N/A 

time_sec 

time_sec 

s 

Time, starting at zero 

Calculated 

N/A 

time_sec_since_midnight 

time_sec_since_midnight 

s 

Time since midnight 

Calculated 

N/A 

time_sec2 

time_sec2 

s 

Time since midnight, 
starting at zero 

Calculated 

N/A 

time_irig 

time_irig 

s 

Time, IRIG style 

Calculated 

N/A 

time_delta 

time_delta 

s 

Change in time between 
data points 

Calculated 

N/A 

time_delta2 

time_delta2 

s 

Change in time between 
data points, starting at 
zero 

Calculated 

N/A 

LeftRPM 

LeftRPM 

rpm 

Same as parameter RPM 

Calculated 

N/A 

latitude_deg 

latitude_deg 

deg 

Same as parameter 
latitude 

Calculated 

N/A 

longitude_deg 

longitude_deg 

deg 

Same as parameter 
longitude 

Calculated 

N/A 
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height_ft 

height_ft 

ft 

Same as parameter 
altitude_gps_wgs84 

Calculated 

N/A 

direction_deg 

direction_deg 

deg 

Same as parameter 
heading 

Calculated 

N/A 

alt_ft 

alt_ft 

ft 

Same as parameter 
altitude_baro 

Calculated 

N/A 

tas_kts 

tas_kts 

kn 

Same as parameter ktas 

Calculated 

N/A 

roll_rate_dps 

roll_rate_dps 

deg/s 

Same as parameter 
rollRate 

Calculated 

N/A 

roll_deg 

roll_deg 

deg 

Same as parameter 
bankAngle 

Calculated 

N/A 

agl_ft 

agl_ft 

ft 

Same as parameter 
laserAlt 

Calculated 

N/A 

windsouth_fps 

windsouth_fps 

ft/s 

Same as parameter 
windVelNorth 

Calculated 

N/A 

windwest_fps 

windwest_fps 

ft/s 

Same as parameter 
windVelEast 

Calculated 

N/A 

pars_engage 

pars_engage 

N/A 

Same as parameter 
PARSengaged 

Calculated 

N/A 

ias_kts 

ias_kts 

kn 

Same as parameter kias 

Calculated 

N/A 

climb_rate_fps 

climb_rate_fps 

ft/s 

Same as parameter 
climbRate 

Calculated 

N/A 

climb_rate_fpm 

climb_rate_fpm 

ft/min 

Parameter climbRate, 
multiplied by 60.0 

Calculated 

N/A 

flyup_active 

flyup_active 

N/A 

Flyup active flag as set by 
UI. Boolean 1 (flyup 
active) or 0 (flyup not 
active). Same as parameter 
flyupActive 

Calculated 

N/A 

altitude_gps_msl 

altitude_gps_msl 

ft 

GPS altitude, above mean 
sea level 

Calculated 

N/A 

N/A 

type 

N/A 

Text string used in 
determining where flyups 
occur in data 

Calculated 

N/A 

N/A 

event 

N/A 

Event number 

Calculated 

N/A 

N/A 

alt_AGL_ft 

ft 

Altitude, AGL (used for 
comparison with laser 
altimeter data) 

Calculated 

N/A 

N/A 

alt_NED_wgs84_ft 

ft 

Altitude, NED, using 
WGS84 ellipsoid 

Calculated 

N/A 

N/A 

alt_NED_wgs84_m 

m 

Altitude, NED, using 
WGS84 ellipsoid 

Calculated 

N/A 

N/A 

GPSVelNorth 

ft/s 

GPS velocity, north 

Calculated 

N/A 

N/A 

GPSVelEast 

ft/s 

GPS velocity, east 

Calculated 

N/A 

N/A 

GPSVelDown 

ft/s 

GPS velocity, down 

Calculated 

N/A 

N/A 

deltaDistN 

ft 

Change in distance, north 

Calculated 

N/A 

N/A 

deltaDistE 

ft 

Change in distance, east 

Calculated 

N/A 

N/A 

deltaDistD 

ft 

Change in distance, down 

Calculated 

N/A 

N/A 

dt_sec 

s 

Differential time 

Calculated 

N/A 

N/A 

GPSVel_fps 

ft/s 

GPS velocity, total 

Calculated 

N/A 

N/A 

GPSVel_kts 

kn 

GPS velocity, total 

Calculated 

N/A 

N/A 

GPSAccelNorth_fpsps 

ft/s 2 

GPS acceleration, north 

Calculated 

N/A 

N/A 

GPSAccelEast_fpsps 

ft/s 2 

GPS acceleration, east 

Calculated 

N/A 

N/A 

GPSAccelDown_fpsps 

ft/s 2 

GPS acceleration, down 

Calculated 

N/A 

N/A 

ART 

s 

Available reaction time 

Calculated 

N/A 

N/A 

FPA 

deg 

Flightpath angle 

Calculated 

N/A 

N/A 

deltaTermAz 

deg 

Number of degrees turned 
until termination occurs 

Calculated 

N/A 

N/A 

deltaTermTime 

N/A 

Time until termination 
occurs 

Calculated 

N/A 
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Appendix B: Analysis Techniques 


Most of the analyses presented in this report consist of straightforward presentations of the data and 
require no further elaboration. A few of the analysis methods were unique, however, warranting some 
additional background description to help future project teams adapt those methods to their own needs. 
Those unique analysis techniques were: 

• Google Earth interface; 

• Available reaction time; 

• Determination of trigger post locations; 

• Determination of worst-case mismatch locations; 

• Trajectory normalization analysis; and 

• Termination logic cross-checks. 

Google Earth Interface 

One of the tools used by the Small Unmanned Aerial Vehicle (SUAV) team for planning test missions 
and analyzing flight-test data was Google Earth. Google Earth provided a markup language known as 
keyhole markup language, or KML. (Keyhole Corp., Mountain View, California, was a technology 
company purchased by Google in 2005). Keyhole markup language allows users to plot locations, lines, 
and polygons within Google Earth for visualization purposes. This same markup language enables Google 
Earth to render images of three-dimensional buildings, text, and other visualization aids. For the purpose 
of analyzing SUAV flight test data, KML proved to be an extremely useful data visualization tool for several 
reasons: 

• Raw flight-test data (SUAV latitude, longitude, and elevation) were plotted using Google Earth, 
which readily allowed users to see where the Dryden Remotely Operated Integrated Drone 
(DROID) airplane flew relative to the nearby terrain features. 

• Algorithm data were also plotted using Google Earth. Algorithm data include trajectory predictions, 
scan patterns, and representative digital elevation model (DEM) data. Plotting algorithm data using 
Google Earth allowed users to determine the effectiveness of the collision avoidance algorithms. 

• The Auto GCAS team was able to use Google Earth to visualize Auto GCAS termination 
predictions. Such visualizations would have been much less useful and far more difficult without 
Google Earth. 

• The team was able to use Google Earth to visualize an available reaction time (ART) by extending 
the actual avoidance trajectory to where the representative DEM data were located. The ART was 
useful for determining a degree of “nuisance potential,” as discussed above within the main body 
of this report. 

During the analysis of the SUAV flight -test data, various software routines were implemented to write 
KML files for use with Google Earth. In order to process KML files for use with Google Earth, the analysis 
team used MATLAB® (The MathWorks, Natick, Massachusetts). The MATLAB utility was the tool of 
choice because it provided a simple interface with which users could easily write scripts which, when 
executed, would write KML files. Of particular interest was the MATLAB Mapping Toolbox™, which 
contained several geodetic calculation functions. The geodetic calculation functions were used to calculate 
trajectories on the WGS84 ellipsoid mathematical model of the surface of the Earth. 

Excel® Test Planning Tool 

The SUAV Auto GCAS test point setups and test cards were produced using an Excel® (Microsoft 
Corporation, Redmond, Washington) worksheet, a sample of which is shown in figure Bl, which 
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implemented both the collision avoidance algorithms (similar to those used on the smartphone) and the 
DEM data set as needed for the SUAV Auto GCAS flight -testing. The smartphone contained DEM data for 
the entire Earth, but the Excel® worksheet needed DEM data only for the local test areas. 
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Figure B 1 . Excel® test planning application. 

The Excel® worksheet provided a very useful, basic simulation of the end-to-end Auto GCAS 
algorithm. The Excel® methodology had been used successfully to support a number of F-16 airplane 
(Lockheed Martin, Bethesda, Maryland) Auto GCAS projects dating back to the early 1990s, and the Excel® 
implementation was also used successfully in support of this SUAV Auto GCAS project. Future related 
projects should take into consideration that any Auto GCAS simulation method will need to have 
functionality similar to the Excel® implementation described herein. The combination of the Excel® 
worksheet simulation and Google Earth was new for the SUAV Auto GCAS project. That combination of 
the two was particularly effective for evaluating and selecting potential flight-test setups. The ability to feed 
simulation results into Google Earth should be a consideration for future Auto GCAS projects. 

The user interface of the Excel® test planning application is shown in figure B 1 . The user could enter 
all of the flight -test point setup parameters (the red numbers shown in figure B 1), and then use the graphical 
user interface buttons (the buttons within the blue fields, also shown in figure B 1) to plot collision avoidance 
algorithm results using Google Earth. 

The test planning process typically began by choosing a simple start location (latitude, longitude, and 
altitude) using Google Earth. A target terrain feature and a desired heading for approaching that terrain 
feature were visually selected. The Excel® - Google Earth combination was then used to refine the setup to 
obtain the desired conditions at collision avoidance initiation. The remaining parameters KCAS (knots 
calibrated airspeed); dive; bank; TCB (terrain clearance buffer); et cetera were entered and the “Run Time” 
along the desired heading was varied until the proximity to terrain indicated the need for an avoidance 
maneuver. Given all of the setup parameters, the results from the Excel® worksheet indicated the expected 
location for initiation of the avoidance maneuver and the direction of the avoidance (left, straight, or right). 
A considerable amount of additional useful information was also provided, such as the expected flightpath 
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and the closest approach to terrain. All of this information could be visualized using Google Earth as 
described below. 

Excel® - Google Earth Interface 

To implement the user interface buttons that are shown within the blue fields in figure Bl, the analysis 
team used Microsoft Visual Basic for Applications (VBA). The VBA is a scripting interface that has been 
included with all builds of Microsoft Office® since version 4.0 (Microsoft Office® 2010 contains VBA 
version 14). The VBA allows Excel® users to facilitate automatic worksheet features and calculations that 
if performed manually would require vast amounts of time. In the case of the information shown in figure 
Bl, the user would have to constantly enter a time in the “Run Time” field in order to determine exactly 
where and when a ground collision avoidance maneuver would occur. The analysis team inserted VBA 
code to automate the process of determining the location of a ground collision avoidance maneuver. 
The user simply clicked on the button labeled “Simulate,” and Excel® ran the calculations until an 
avoidance, as shown in figure B2, was found. 
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Figure B2. Avoidance maneuver initiation example. 

Figure B3 displays the results of clicking on the “Plot in Google Earth” command button that is shown 
in figures Bl and B2. In figure B3, the black line is the “pre-avoidance” flightpath (that is, the predicted 
flightpath until the point of an Auto GCAS maneuver). When the flightpath was expected to be straight 
(a 0 initial bank value in merged cells A4/A5 as shown in figure B2), the program drew a straight line in 
Google Earth to represent a straight pre-avoidance flightpath. That straight line began at the initial 
longitude-latitude-altitude coordinates and along the heading specified by the user, and ended at the location 
of the avoidance maneuver initiation. 
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Figure B3. Result from clicking “Plot in Google Earth” button illustrated in figure B2. 

If a turning flightpath was expected, the pre-avoidance flightpath displayed as curved in Google Earth. 
The length of that curved black line was based on the user-specified heading change, using a radius 
established by the user-specified bank angle and load factor. For example, in figure B2, merged cells 
G14/G15 were set to 45, which meant that the curved black line in Google Earth represented a turn through 
a heading change of 45 deg prior to the Auto GCAS avoidance maneuver initiation. In the example 
worksheet shown in figure B2, the load factor of 1 .2 g entered in merged cells C2/C3 determined the radius 
of the curved flightpath. Visualizing the results in Google Earth enabled the user to determine where a 
turning flight-test maneuver needed to begin in order to result in an avoidance initiation at the desired 
location and flight conditions. 

The light green cylinders in figure B3 represent the Auto GCAS algorithm scan width, which is a 
function of the range along the avoidance prediction path (the scan width circles increase in diameter with 
range from the initiation point). The scan width near the initiation point was based on the horizontal 
uncertainty (from merged cells G12/G13 in figure B2). The dark green discs (“wagon wheels”) in figure 
B3, which lie slightly above the light green cylinders, represent the sum of the terrain clearance buffer 
(TCB from merged cells A13/A14 in figure B2) and vertical uncertainty (from merged cells G10/G11 in 
figure B2). Whenever any portion of the buffered terrain (represented by the dark green discs in figure B3) 
intersected with the trajectory prediction (represented by the blue line in figure B3) the result would indicate 
the coordinates for the expected avoidance initiation (indicated by the white arrow in figure B3). 

The “Plot In Google Earth” buttons shown in figures B 1 and B2 allowed the user to display KML paths 
within Google Earth that represented the ground collision avoidance trajectory predictions. An 
Excel® - MATLAB® interface was required in order to use MATLAB® functions that were needed to 
produce KML files. The MATLAB® application and Excel® communicated through the Microsoft 
Component Object Model (COM). By implementing a COM interface, MATLAB® and Excel® were able 
to easily exchange data in real time. 
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In addition to pre-flight predictions using the Excel® tool, the analysis team also plotted flight -test data 
from the DROID within Google Earth. Figure B4 represents an actual avoidance maneuver taken from 
flight-test data. The black extrusion represents the actual DROID flightpath before and after the avoidance 
maneuver. The red extrusion represents the actual DROID flightpath during the avoidance maneuver. 
Terminology for the green cylinders and dark green “wagon wheels” remains the same as that used for 
figure B3. The orange cubes represent the DEM data for the GCAS valley test area. It can be seen in figure 
B4 that neither the left nor straight trajectory was selected (because the trajectory predictions were well 
below the buffered terrain within the scan patterns). Figure B4 also shows that the actual flightpath for the 
selected right avoidance maneuver closely followed the trajectory prediction for this example. Additional 
examples for Google Earth plots of flight-test data are shown in the main body of this report as well as 
below within this appendix. 
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Figure B4. Example flight-test data. 

Available Reaction Time 

The premise of the “Available Reaction Time (ART)” calculation was to determine the amount of time 
within which a pilot would need to react were an Auto GCAS maneuver not initiated. Available reaction 
time was defined as the amount of time after initiation of the Auto GCAS maneuver within which the same 
maneuver could have been delayed while still avoiding terrain. The reason for calculating ART was to 
determine the “nuisance potential” of the system. A formal study has not yet been performed to quantify 
the ART nuisance boundary for UAVs similar to the DROID. For the purpose of this demonstration project, 
ARTs in excess of six seconds were considered possible nuisances, while those less than four seconds were 
considered probable non-nuisances. A negative ART indicates that the avoidance maneuver would not 
prevent the DROID from flying into the terrain, or in this case, the terrain plus TCB. 

To calculate ART, the trajectory of the DROID after avoidance maneuver initiation was extrapolated 
as though the avoidance maneuver had been delayed. Figure B5 shows a setup maneuver, avoidance 
activation, and avoidance maneuver but without an extrapolated trajectory. The extrapolated trajectory 
consisted of three segments: the delay segment, the delayed avoidance maneuver segment, and the 
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post-termination maneuver segment. The delay segment, shown in green in figures B6, B7, and B8, 
estimated the DROID ’s path had no avoidance maneuver been initiated. The delayed avoidance maneuver 
segment, shown in dark red in the same three figures, used the same avoidance maneuver path that occurred 
in flight-testing, delayed by the selected time increment. The post-termination maneuver segment, shown 
in dark blue in these figures, attempted to estimate the trajectory as though the avoidance maneuver had 
continued after termination of the flight-test maneuver. The delay segment was progressively increased 
until any of the three segments intersected with the digital terrain. The ART was then defined at the value 
of the delay segment one frame before the extrapolation intersected with the digital terrain. 



Figure B5. Actual trajectory. 
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Figure B6. Three-segment extrapolation at intersection with terrain. 
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Figure B7. Three-segment extrapolation one frame before terrain intersection. 



Figure B8. Three-segment extrapolation from above. 

Figures B5, B6, and B7 show flight 19 event 16. Figure B5 shows the actual trajectory of the DROID, 
including the path during the setup maneuver prior to the avoidance activation and the actual avoidance 
maneuver. Figure B6 shows the three segments of extrapolation delayed 2.2 s, resulting in part of the 
trajectory intersecting with the digital terrain. Fig. B7 shows the three segments one frame earlier, when 
the extrapolation was delayed 2.0 s and the trajectory just missed the digital terrain. For this example, this 
technique resulted in an ART value of 2.0 s. 
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The delay segment treated the DROID as a point mass and used basic particle kinematics to extrapolate 
using the aircraft states at the original activation, ignoring acceleration in the z-axis. The delayed avoidance 
maneuver was a copy of the actual avoidance maneuver, rotated about the z-axis to align with the delay 
segment, so that the flightpath continued smoothly into the delayed avoidance maneuver. The flightpath 
after the delayed avoidance maneuver was calculated differently, depending on whether the avoidance 
maneuver was over smooth terrain or not. 

Over smooth terrain, the important factor in determining whether the extrapolated flightpath would 
intersect with the digital terrain was the movement of the DROID in the vertical plane, because the digital 
terrain was of approximately the same height throughout the surrounding area. In mountainous areas, 
however, the movement of the DROID in the horizontal plane dominated the consideration of whether the 
extrapolated flightpath would intersect the digital terrain. For this reason, over smooth terrain, the actual 
flightpath of the DROID after avoidance maneuver termination was used. Over mountainous terrain the 
trajectory prediction (as calculated at activation) was used to estimate the flightpath after avoidance 
maneuver termination. The trajectory prediction was used for mountainous terrain instead of the actual 
flightpath because the safety pilot often took control shortly after normal termination (as planned for each 
test point). The trajectory prediction was considered the best estimate for the flightpath that would have 
occurred had the safety pilot not taken control. It was not necessary to use the trajectory prediction for 
smooth terrain because there were few of those events and the safety pilot did not take control until after 
the point at which the extrapolated trajectory intersected with digital terrain. 

The best available digital terrain model was used to determine the intersection with the extrapolated 
flightpath. For these ART analyses, the one-third-arc-second National Elevation Dataset (NED) was used. 
The delay was incremented in time steps that were the same as the recorded data on the smartphone 
(roughly 0.2 s). The specific magnitude of each time step was dependent on the smartphone data time steps 
because the smartphone calculations were somewhat asynchronous and did not calculate at precise, regular 
intervals. 

Three Segment Extrapolation Methods 

As discussed above, the DROID trajectory was extrapolated in three segments: the delay segment, the 
delayed avoidance maneuver segment, and the post-termination maneuver segment. A top view of these 
three segments at the point where the ART value was determined for flight 19 event 16 (as viewed from 
above) is shown in figure B8. This figure shows that the three-segment extrapolation method creates a 
continuous trajectory. 

Delay Segment 

For the first segment of the extrapolated flightpath for ART calculations, the SUAV was treated, for 
simplicity, as a point mass. In general, ART calculations were based on particle kinematics, with the 
exception that vertical accelerations were ignored, and the DROID was assumed to experience a constant 
rate of climb or descent. 

In the case of the ART analysis, vertical accelerations were not taken into account for two reasons. The 
first reason was the extremely low signal -to-noise ratio in the z-axis Piccolo II autopilot accelerometer data 
(see figure B9). The second reason was that the DROID often flew in near-equilibrium flight (lift equaling 
weight, and thrust equaling drag) as commanded by the autopilot. In addition, the small size of the DROID 
made it extremely susceptible to even slight changes in wind direction, wind speed, turbulence, and other 
atmospheric conditions. In calculating the ART for the F-16, the maneuvers were far “larger” in the sense 
of the scale of the F-16; therefore all accelerations (north/east/down) had to be taken into account. 
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g-level at 40° bank limit 


Figure B9. Impact of atmospheric turbulence on measured vertical acceleration. 

In the case of the ART analysis as applied to the SUAV project, the noisy z-axis accelerometer data 
induced inappropriate and unlikely estimated flightpaths. The Piccolo II autopilot kinematics data (north 
and east velocities and accelerations) also failed to record; therefore, the analysis team generated the 
estimated flightpaths from known position and velocity data (latitudes, longitudes, and climb rate). 
Velocities were obtained from changes in latitude and longitude, and accelerations were further 
differentiated from changes in velocity. The technique of differentiation in order to obtain velocities and 
accelerations was not ideal because differentiation often amplified signal noise. 

To counteract the effects of signal noise due to differentiation, the analysis team applied a generic 
smoothing routine to the north/east velocities and accelerations; vertical acceleration remained too noisy to 
be useful even after smoothing attempts. Figure B9 shows a typical sample of the measured z-acceleration. 
The upper limit of the normal maneuvering envelope of the DROID as configured (1.3 g given the 
preprogrammed bank limit of 40 deg) is also shown in figure B9. This clearly shows that the noise in the 
data captured was induced by atmospheric turbulence, not the normal maneuvering of the DROID. 

Delayed Avoidance Maneuver 

The delayed avoidance maneuver flightpath estimated what the DROID would have done had the same 
avoidance maneuver been executed after some time delay. Since the heading may have changed during the 
delay segment, the delayed avoidance maneuver was rotated to align with the heading at the end of that 
delay segment. A new initial heading and a new position (latitude, longitude, and altitude) were chosen to 
match the end of the delay segment flightpath, and from this position, the flightpath angles and changes in 
heading of the original avoidance maneuver were applied. Changing the initial heading but recreating the 
same change in heading effectively “rotated” the avoidance maneuver about the z-axis and maintained 
continuity in the horizontal flightpath between the delay segment and the delayed avoidance maneuver. 
Rotating the avoidance maneuver about the y-axis was not necessary because vertical acceleration was 
ignored and the flightpath angle did not change during the propagation. 
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Figures B6 and B8 show that the method of rotating the flightpath of the original avoidance maneuver 
and appending it to the end of the delay segment resulted in a continuous propagated flightpath. Ignoring 
the vertical acceleration did not induce a significant discontinuity in the vertical flightpath at the point 
where the delay segment met the delayed avoidance maneuver. This method worked because most 
flight-test maneuvers were near 1 g during the approach to the avoidance maneuver. If the maneuvering of 
the DROID at the initiation of the avoidance maneuver were more dynamic, a different propagation method 
would have been required. 

Post-Termination: Mountainous Terrain 

When the avoidance maneuver ended, if neither the safety pilot nor ground control gave instructions to 
the DROID, the DROID would stay in the climbing turn last commanded during the avoidance maneuver. 
In other words, the autopilot made no effort to return the DROID to level flight before terminating. Over 
mountainous terrain, it was the curvature of this climbing turn that most accurately determined whether the 
extrapolated flightpath would intersect with digital terrain. The actual post-termination flightpath could not 
be used because it was normal test procedure for the safety pilot to take control soon after the avoidance 
maneuver had terminated. Therefore it was determined that the best estimate for propagating the flightpath 
of the DROID after termination was based on the steady climbing turn calculated as part of the trajectory 
prediction from when the avoidance maneuver was initiated. 

To make the estimation of flightpath as continuous as possible, the point along the trajectory prediction 
where the heading most closely matched the heading at the end of the delayed avoidance maneuver was 
used as the beginning of the post-termination segment. This flightpath was then translated in three 
dimensions to meet the end of the delayed avoidance maneuver. This method may result in some 
discontinuity in flightpath angle, but since the slope of the flightpath of the DROID was so much less than 
the slope of the digital terrain, small offsets in extrapolated altitude were less significant than the latitude 
and longitude of the DROID during this segment. Also, this method guaranteed that the flightpath angle 
over the entire extrapolation was a flightpath angle sustainable by the DROID. 

Flight 19 event 10 having flown over mountainous terrain, it was used to demonstrate this method for 
the post-termination segment. Figures B6 and B8 show that this method created a smooth transition (that 
is, revealed no obvious discontinuities) from the delayed avoidance maneuver to the post-termination 
segment. 

Post-Termination: Smooth Terrain 

Over smooth terrain, the most important factor in determining ART was the vertical flightpath shortly 
after the avoidance maneuver. In order to obtain the most accurate trajectory propagation, the actual 
flightpath after termination of the avoidance maneuver was used (instead of the trajectory prediction method 
that was used for mountainous terrain). This method worked over smooth terrain because there were a few 
seconds until the safety pilot took control, and that amount of time was sufficient to provide enough data 
for the propagation. The actual flightpath after termination, up until the safety pilot took control, was 
appended to the end of the delayed avoidance maneuver. That flightpath was rotated and translated similar 
to the way in which the delayed avoidance maneuver was appended to the delay segment. This ensured 
continuity in both heading and flightpath angle. 

The post-termination segment of the extrapolated flightpath over smooth terrain was significantly less 
important to the ART calculation than that segment over mountainous terrain. Most avoidance maneuvers 
over smooth terrain terminated during a slight climb, which was sufficient to clear smooth terrain. 
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Comparison to Digital Terrain Truth Data 

Once the longitude, latitude, and altitude of the DROID were extrapolated for the entire three-segment 
trajectory, the extrapolated trajectory was compared to “best source” data for the digital terrain. For this 
ART analysis the best source for truth data was considered to be the one -third-arc -second NED. At every 
point of longitude-latitude in the extrapolated flightpath (shown by solid colored vertical lines in Google 
Earth snapshots in figures B6, B7, BIO, and B 1 1 ) the height of the NED was found. The TCB for each 
event was then added to the NED as a way to normalize across every test run, since the Auto GCAS system 
interpreted the “ground” to be at digital terrain height + TCB. The NED altitude plus TCB is represented 
by a tan line in these figures. Because flight 19 event 16 had a TCB of 0 ft and Google Earth also used the 
one-third-arc-second NED, these tan lines are barely visible above the ground as it is displayed in Google 
Earth depiction of figures B6 and B7. Therefore, flight 19 event 7, with a TCB of 100 ft, was used to 
demonstrate this concept in figures BIO and B 1 1 . Figure BIO shows the delayed avoidance maneuver at 
the frame when the propagated trajectory was just clear of the buffered terrain (NED + TCB). That frame 
in the propagation was used to define the ART value. Figure B 1 1 shows the delayed avoidance maneuver 
one frame later, when the propagated trajectory intersected with the NED + TCB. The vertical tan line 
shows the first point along the trajectory where the NED + TCB line was above the trajectory. The 
intersection in this event happened during the delayed avoidance maneuver segment, but it sometimes 
happened in the post-termination segment (as in the case of flight 19 event 16). 



Figure BIO. Extrapolated trajectory above NED + TCB (at the ART). 
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Figure B 1 1 . Extrapolated trajectory below NED + TCB (one frame after the ART). 

Determination of Trigger Post Locations 

As described in the “Generic ‘Sense Terrain’ Module” section in the main body of this report, the DEM 
was decompressed as a rectangular grid of posts with latitude, longitude, and altitude, and treated as a flat 
polygon surrounding that post at the same altitude. The trigger post analysis seeks to determine which 
specific post caused the avoidance maneuver. 

The trajectory prediction and related scan circles in the direction of the avoidance were used as the 
basis for this analysis. In the case of flight 16 event 6, which is depicted in figures B12, B13, and B14, the 
avoidance was to the right, so the right trajectory prediction was analyzed. Within the Auto GCAS 
algorithm, the digital terrain was represented by scan circles at the altitude of the highest terrain polygon 
within the radius of each circle. That altitude was raised further to account for the flight-test buffer 
(the TCB ) and the built-in buffer (vertical uncertainty) since the trajectory prediction was being compared 
to DEM + TCB + vertical uncertainty altitude. 
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Figure B12. Trajectory prediction and scan circles viewed from above. 



DEM altitude 


Scan circle associated with trigger 
post (at buffered altitude) that the 
trajectory prediction first goes under - 


DEM + TCB + vertical 
uncertainty 


Trajectory prediction ■ 


\ / 

\ / BpS 




. . , ©2012, Map data: Google, SIO. NOAA, U.S. Navy, NGA. GEBCO 


feet. 


200 


150116 


Figure B13. Trajectory prediction and scan circles viewed from side. 
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Figure B 14. Trigger post location relative to scan circle. 

In figure B13, the scan circles are shown in light green (at the DEM altitude) and dark green 
(at the DEM + TCB + vertical uncertainty altitude). The trajectory prediction is shown in blue. When the 
trajectory prediction was lower than one of the buffered scan circles the avoidance maneuver was triggered. 
The trigger post was associated with the polygon that gave this scan circle its height. In figure B13, it can 
be seen that the 8th light green scan circle (from the left) is paired with the first dark green buffered circle 
that the trajectory prediction passes underneath. Figure B14 shows this 8th scan circle and the surrounding 
DEM polygons. In this case the scan circle just touches the corner of the polygon associated with the trigger 
post. The practical significance of this implementation was that the DEM posts which triggered avoidance 
maneuvers tended to be outside of the scan circles and therefore created some additional horizontal buffer 
away from the actual terrain. 

Determination of Worst-Case Mismatch Locations 

In order to evaluate the accuracy of the trajectory prediction, the worst -case mismatch between the 
actual ground track compared to the predicted ground track was found for each event. 

The actual ground track always included the automated avoidance maneuver. In some cases, the actual 
ground track also included the time after the automatic system terminated in order to determine when the 
DROID was at its minimum altitude above the ground (as long as the safety pilot did not take control). In 
figures B15 and B16, the actual ground track is shown by a red dotted line. The predicted ground track and 
half-scan width, as determined by the algorithm, are shown in blue and purple solid lines, respectively. 
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Figure B15. Worst-case point: inside of the scan. 



Figure B16. Worst-case point: outside of the scan. 

In some cases, the ground track was never farther away from the predicted ground track than the 
half-scan width. The DROID stayed above the terrain included in the scan pattern. In such cases, the worst 
case was the point at which the actual ground track was farthest from the prediction. Figure B15 shows the 
worst-case analysis plot for such a case, flight 12 event 1. The red actual ground track is clearly inside the 
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purple scan, and the worst case is the point at which the red actual ground track is farthest from the blue 
predicted ground track. 

In other cases, the actual ground track was farther away from the prediction than the half-scan width. 
In these cases, the DROID flew over terrain not necessarily accounted for by the algorithm. In such cases, 
the worst case was the point at which the flightpath was farthest outside the scan. Figure B16 shows the 
worst-case analysis plot for such a case, flight 18 event 6. The red actual ground track extrudes past the 
purple scan, and the worst case is the point at which the red actual ground track is farthest outside the purple 
scan. 

The methods for finding the distance along the trajectory prediction and the half-scan width at each 
predicted ground track point are described in the following section. 

Trajectory Normalization Analysis 

In order to assess how well the overall Auto GCAS algorithm was working, a normalization analysis 
was used to compare key points from multiple test runs all on the same plot. This normalization method 
was used to show key points at the trigger posts and the location of the worst -case mismatch between the 
actual trajectory compared to the prediction as described in the appendix sections “Determination of Trigger 
Post Locations” and “Determination of Worst-Case Mismatch Locations.” The following discussion 
assumes a known latitude and longitude for each point in question. 

The premise of the normalization analysis was that any desired point could be characterized by a 
distance along the trajectory prediction and distance perpendicular to the trajectory prediction. These 
distances could also be expressed as percentages of the total length and percentages of the corresponding 
width. 

Scans for individual flight-test runs had different shapes and lengths depending on factors such as initial 
turn rate, airspeed, and wind. In Figures B17 through B22, comparisons of the trajectory prediction to the 
right were generated by changing the initial turn rate (bank), airspeed, and wind, respectively. A similar set 
of scans could be generated for a trajectory prediction to the left or straight. In each set of comparison 
figures, the trajectory prediction shown on the left-hand side of the page is based on the DROID initially 
traveling at 0 deg bank and 75 KTAS with no wind. Figure B 17 compares the no-bank trajectory prediction 
to a trajectory prediction with an initial 40-deg left bank in figure B18. The DROID needs time to adjust 
from turning left to turning right, so the initial opposite bank makes the turn somewhat wider. Conversely, 
an initial bank in the same direction of the avoidance makes the turn tighter. Figure B19 compares the 
75-KTAS trajectory prediction to a trajectory prediction with an initial speed of 60 KTAS in figure B20. 
The slower airspeed results in a tighter turn radius. Figure B21 compares the trajectory prediction with no 
initial crosswind to a trajectory prediction with a 20-kn crosswind from the right in figure B22. A crosswind 
of that magnitude from that direction tightens the turn radius considerably, while a crosswind in the opposite 
direction widens the turn radius. 
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Figure B17. Trajectory prediction with no initial 
bank. 


Figure B18. Trajectory prediction with initial 
40-deg left bank. 
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Figure B19. Trajectory prediction with 75-kn Figure B20. Trajectory prediction with 60-kn 
initial speed. initial speed. 
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Figure B21. Trajectory prediction with no initial Figure B22. Trajectory prediction with 20-kn 
wind. initial crosswind. 

A single scan shape was selected to use as a reference for showing the key points from all of the 
flight-test runs. This reference scan shape was selected from flight 12 event 4, initiated at 73 KTAS, 
0.5 deg bank, with a negligible crosswind. By normalizing the location of each point in question relative to 
the reference scan shape, those points could all be placed on one plot even if the original avoidance 
maneuver was to the left, straight, or right. The results shown in figures 54 and 58 of the main body of this 
report used the techniques discussed in the following paragraphs. The results of this analysis are also shown 
on histograms in figures 55, 56, 59, and 60 of the main body of this report, to provide an alternative 
summary. 

Finding Distances 


The trajectory prediction on the smartphone determined the centerline at multiple bin locations. The 
spacing between each bin was a function of how dynamic the expected avoidance maneuver would be at 
that location. The bins were spaced closer together during dynamic portions of the maneuver such as during 
g-onset or roll-rate onset. The bins were spaced farther apart if the expected avoidance maneuver at that 
location would be relatively stabilized. 

Given the latitude and longitude of individual bin locations along the centerline of a trajectory 
prediction from flight-testing, the first steps were to find the total length of the centerline and the scan 
pattern width at each bin location. A visual representation of this method is shown in figure B23. Each 
distance point is shown as a blue dot. At the beginning of the trajectory (the most dynamic portion of the 
maneuver), the dots are so close together that they appear to form a solid line. The total distance is the sum 
of the straight line distances between neighboring distance points. 
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Figure B23. Method for finding total distance along trajectory prediction. 

The scan pattern width could then be found at any distance point along the trajectory prediction using 
equation (Bl). In order to match the values used during SUAV Auto GCAS flight test in equation (Bl), 
HorizontalUncertainty = 50 ft, and UncertaintyGrowthAngle = 10° for turning scans and 5° for 
straight scans. The results of this method are shown in figure B24. By plotting the purple half-scan width 
on each side of the blue trajectory prediction, the entire scan is shown. 
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Figure B24. Half-scan width. 
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Once the total length of the centerline and the scan pattern width at each point along the entire length 
were known, the next step was to identify where key points of interest from a flight -test maneuver were 
located relative to the centerline. As mentioned at the beginning of this section, those key points could be 
trigger posts or they could be the location of the worst-case mismatch between the actual trajectory and the 
prediction. Given the latitude and longitude of a key point in question, distances along the centerline and 
perpendicular to the centerline were needed. 

The two distance point locations along the centerline closest to the key point in question were found by 
using a distance function to find the distance from every point location along the centerline to the key point. 
The total distance along the centerline from maneuver initiation up until the distance point closest to the 
key point in question was determined by using the sum of the distances between neighboring distance point 
locations, as already described in the discussion above of figure B23. 

To find the distance perpendicular to the centerline, distance functions were used to determine the 
perpendicular distance, as shown in figure B25. The two closest bin locations were mathematically 
connected by a straight line. A perpendicular to that line was determined which also intersected with the 
key point. The length of this line was used as the distance perpendicular to the centerline. 



Figure B25. Method for finding perpendicular distance at a given point along the trajectory prediction. 
Nondimensionalizing Distances and Plotting on a Representative Trajectory Prediction Algorithm 


In order to make the distances nondimensional, the perpendicular distance was divided by the half-scan 
width at that location to convert into a percentage. Similarly, the distance along the trajectory prediction 
from maneuver initiation to the key point was converted into a percentage by dividing by the total length 
of the trajectory prediction. In addition, to transpose a point from a right or straight trajectory prediction 
onto the intended reference (left trajectory prediction), the key point location inside or outside of the 
trajectory prediction was used. The right trajectory prediction shown in figure B26 shows a point in orange 
that is 50 percent along the trajectory prediction length, and 75 percent of the half-scan width inside the 
curve of the trajectory prediction. The right trajectory prediction shown in figure B26 also shows a point in 
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blue that is 50 percent along the trajectory prediction length, and 75 percent of the half-scan width outside 
the curve of the trajectory prediction. The left trajectory prediction shown in figure B26 shows how the 
orange and blue points were transposed onto the reference left trajectory prediction. 
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Figure B25. Example for non-dimensional key point locations. 

Termination Logic Cross-Checks 

When an SUAV avoidance maneuver was not terminated by the safety pilot, the Auto GCAS algorithm 
determined when the avoidance maneuver was no longer necessary and returned control to the ground 
control operator. In order to assess the timeliness of the avoidance maneuver termination, the flight-test 
results were compared with an ideal termination defined by generating a straight line tangent to the 
avoidance flightpath. A straight line tangent (including the current climb rate) was used as a way to identify 
that there was no obstructing terrain directly in front of the DROID. Although other methods could have 
been used, this was considered the simplest and would most directly correlate with the view of the pilot 
(in this case, the view provided by the forward-looking video camera). When the straight tangent line was 
projected to be clear of the DEM terrain for three consecutive time frames (approximately 0.2 s per frame), 
that third frame was considered the ideal termination. 

The puipose for these termination logic cross-checks was to determine whether the Auto GCAS 
algorithm terminated the maneuver earlier than it should have, at about the right time, or later than 
necessary. As a general result, when the DROID maneuvered left to avoid terrain, the software logic caused 
the avoidance maneuver to terminate earlier than it should have. For a right avoidance, the Auto GCAS 
maneuver tended to terminate later than necessary. The overall results are described in the main body of 
this report; the methods used are described below. 

Figure B27 illustrates how the Auto GCAS algorithm determined when to terminate the avoidance 
maneuver using an example from flight-testing. The black line in figure B27 represents the actual flightpath 
of the DROID prior to the avoidance maneuver. The navy blue line in figure B27 represents the trajectory 
prediction at initiation (in this case, the Auto GCAS algorithm determined that the DROID should avoid 
terrain by executing a left turn). The red line in figure B27 represents the actual flightpath during the 
avoidance maneuver. To determine when an avoidance maneuver should be terminated, the Auto GCAS 
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algorithm computed a straight trajectory at every time frame throughout the maneuver. The labeled 
“1st blue line” in figure B27 represents the straight trajectory prediction one frame before the trajectory 
prediction was clear of the buffered digital terrain (green rectangular polygons). The labeled “2nd blue line” 
in figure B27 represents the straight trajectory prediction at the frame when the trajectory prediction was 
first clear of the buffered digital terrain. The straight trajectory predictions do not appear straight in figure 
B27 because of the P-factor, described in the main body of this report. The Auto GCAS algorithm 
terminated the avoidance maneuver when three consecutive frames were clear of terrain. 
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Figure B27. Example avoidance maneuver. 

To accomplish termination logic cross-checks, the Auto GCAS team used MATLAB® to implement 
the calculations combined with Google Earth as a visualization aid. Using Google Earth KML files, violet 
straight lines were drawn tangential to the red avoidance maneuver flightpath in figures B28 through B30. 
To avoid clutter, these violet lines were only drawn every fifth frame (there is roughly 1 s between each 
line). 
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Figure B28. Tangential lines (violet) drawn from the avoidance flight path (red). 
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Figure B29. Right-turning avoidance terminated late. 
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Figure B30. Left-turning avoidance terminated early. 

Next, three arc-second buffered DEM terrain tiles (represented by the green polygons) were added. The 
buffered terrain added the TCB value to the DEM altitude but did not include any built-in buffers. 
Therefore, the results from any test run could be evaluated in the same manner as if the TCB were set to 0. 
The DEM terrain tiles were sized at three arc-seconds to be consistent with the resolution used by the Auto 
GCAS algorithm and to minimize computational time. This calculation being post-flight, the theoretical 
accuracy could have been improved using higher resolution DEM tiles (as fine as the one -third-arc-second 
resolution of the NED source data) but that increased accuracy was not considered necessary for this 
analysis. 

The ideal termination heading was defined to be when the green DEM polygons did not block three 
consecutive tangential paths (as shown by the three lighter colored violet lines in figures B28 and B29). 
The determination of when the tangent lines no longer intersected with the DEM terrain was accomplished 
as a numerical calculation but is shown using Google Earth to help visualize the concepts. 

Figures B28 and B29 illustrate termination calculations for similar right-turning avoidance maneuvers. 
Figure B28 shows the avoidance maneuver as viewed from almost directly above. Figure B29 shows the 
same maneuver from the perspective of a lower viewing angle. The darker violet lines represent the 
tangential paths that were blocked by terrain (drawn every five frames), and the three right-most lighter 
violet lines represent the three-frames-of-persistence clear of terrain (drawn every frame). In these cases, 
the right-turning avoidances illustrated in figures B28 and B29 indicate that the avoidance maneuver 
terminated approximately 26 to 29 deg later than necessary. 

The short vertical lines along each tangential path represent a distance equivalent to one arc-second. 
Greater accuracy could have been achieved with smaller intervals for the tangential paths (that is, one-third 
arc second instead of one arc-second resolution) but computational time would have been increased 
significantly as a result. 
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Figure B30 illustrates termination calculations for a left-turning avoidance maneuver. The red 
flightpath in figure B30 once again represents the actual avoidance maneuver path up to the point at which 
the Auto GCAS algorithm terminated the maneuver. The violet straight lines (drawn every fifth frame) 
represent the tangential paths along the red actual avoidance path. The orange semicircle represents an 
extrapolated avoidance trajectory that the DROID would have taken had it continued the avoidance 
maneuver. The dark-orange straight lines (drawn every fifth frame) represent the tangential paths along the 
extrapolated orange semicircle. Finally, the three straight yellow lines (drawn at each frame) represent the 
consecutive tangential paths which do not intersect with the green DEM polygons. 

To determine an extrapolated avoidance trajectory, several new elements were needed. Since the 
smartphone hosting the Auto GCAS algorithm did not use a consistent time interval for each frame, an 
average time interval was selected using the last five time increments in the red portion of the actual 
avoidance maneuver (see figure B3 1). Next, a constant radius was calculated for the extrapolated avoidance 
maneuver based on the arc between the last two points of the actual avoidance maneuver. This radius was 
calculated from equation (B2): 


s = 9 ■ R 


(B2) 


where 9 is the heading change calculated from the last two points in the red avoidance path in figure 
B30, and 5 is the arc distance between those two points. In this example case, the left-turning avoidance 
maneuver shown in figure B30 terminated approximately 32 deg earlier than it should have. Although this 
extrapolation method worked reasonably well on most runs, it was also susceptible to noise in the source 
data, causing some uncertainty in the results. An alternative method could use an extrapolated radius based 
on the average arc over the previous several frames. 
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Figure B31. Differential time element illustration. 

For the extrapolated mns the delta time and delta heading were based on the new incremental elements 
described above. 
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Appendix C: Flight Log 


This appendix presents a summary of all flights that were related this project. Table Cl presents the first few flights that were accomplished on 
the DROID aircraft to obtain basic trajectory prediction data along with the SUAV system checkout flights. Table C2 presents all of the SUAV test 
flights that were accomplished to evaluate the overall system and obtain test data. 


Table Cl. Preliminary flights. 


Flight 

number 

Flight 

date 

Duration, 

min 

Smartphone 

location 

Test site 

Test types* 

Notes 

DROID #1 

4/14/2011 

47 

N/A 

North Base 

10 sequential axis PARS runs** 

Normal inputs to Piccolo II 

DROID #2 

4/14/2011 

33 

N/A 

North Base 

8 sequential axis PARS runs** 

Normal inputs to Piccolo II 

DROID #3 

4/14/2011 

10 

N/A 

North Base 

No test runs** 

Normal inputs to Piccolo II 

DROID #4 

4/14/2011 

29 

N/A 

North Base 

9 sequential axis PARS runs** 

Normal inputs to Piccolo II 

DROID #5 

4/14/2011 

35 

N/A 

North Base 

13 sequential axis PARS runs** 

Normal inputs to Piccolo II 

SUAV #1 

9/28/2011 

44 

Van 

North Base 

9 combined axis PARS runs** 

UI inputs to Piccolo II 

SUAV #2 

9/28/2011 

42 

Van 

North Base 

7 Auto GCAS functional checks 

None 

SUAV #3 

9/28/2011 

51 

Van 

North Base 

17 combined axis PARS runs** 

UI inputs to Piccolo II 

SUAV #4 

10/7/2011 

26 

Van 

Rosamond Lakebed 

3 Auto GCAS runs 

Intermittent RPM sensor 

SUAV #5 

10/7/2011 

15 

Van 

Rosamond Lakebed 

No test runs 

Failed RPM sensor 

SUAV #6 

10/7/2011 

27 

Van 

Rosamond Lakebed 

3 Auto GCAS runs 

Intermittent RPM sensor 

SUAV #7 

10/18/2011 

53 

Van 

Rosamond Lakebed 

12 Auto GCAS runs 

TM dropouts near hill 

SUAV #8 

10/18/2011 

51 

Van 

Rosamond Lakebed 

2 Auto GCAS runs 
1 1 combined axis PARS runs 

None 


Notes: 

* The number of runs listed represents the runs attempted. Some runs were not completely successful for a variety of reasons. 

** The six flights identified with double asterisks were accomplished to determine the parameters needed to define the trajectory predictions. Pilot Activated 
Recovery System (PARS) maneuvers were initiated in each axis to obtain the required data. PARS maneuvers were executed using the same command sequence 
intended for the corresponding flyup maneuvers. 
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Table C2. Primary test flights. 


Flight 

number 

Flight 

date 

Duration, 

min 

Smartphone 

location 

Test site 

Test types* 

Notes 

SUAV #9 

10/21/2011 

55 

Van 

GCAS valley 

13 Auto GCAS runs 

Top of small hill 
TM dropouts near hill 

SUAV #10 

10/21/2011 

55 

Van 

GCAS valley 

1 1 Auto GCAS runs 

Top of small hill 
TM dropouts near hill 

SUAV #11 

11/7/2011 

49 

Van 

GCAS valley 

7 Auto GCAS runs 

Base of small hill 
TM much improved 

SUAV #12 

11/7/2011 

35 

Van 

GCAS valley 

6 Auto GCAS runs 

Medium hill 

SUAV #13 

3/5/2012 

59 

Aircraft 

Rosamond Lakebed 

6 Auto GCAS runs (no flyups) 
1 nuisance test rehearsal 

No flyups: traced to Piccolo II roll rate 
values 

SUAV #14 

3/15/2012 

32 

Aircraft 

GCAS valley 

5 Auto GCAS runs 

Smartphone data did not record 

SUAV #15 

3/15/2012 

2 

Aircraft 

GCAS valley 

No test runs 

Smartphone dislodged on takeoff 

SUAV #16 

3/15/2012 

53 

Aircraft 

GCAS valley 

9 Auto GCAS runs 

FAIL states disrupted testing 

SUAV #17 

3/29/2012 

59 

Van 

GCAS valley 

13 Auto GCAS runs 

Near Fremont Peak 

(Smartphone back in van to allow testing 
without disruptions due to FAIL states.) 

SUAV #18 

3/29/2012 

63 

Van 

GCAS valley 

1 1 Auto GCAS runs 

Lakebed and medium hill 
Guest pilots. 

SUAV #19 

3/29/2012 

54 

Van 

GCAS valley 

12 Auto GCAS runs 

Medium hill 

SUAV #20 

5/31/2012 

40 

Aircraft 

GCAS valley 

7 nuisance test ridge crossings 

Small hill 

(Smartphone back in DROID with 
improved FAIL states.) 

SUAV #21 

5/31/2012 

52 

Aircraft 

GCAS valley 

12 Auto GCAS runs 
3 nuisance test valley patrols 

Medium hill 


Note: 

* The number of runs listed represents the runs attempted. Some runs were not completely successful for a variety of reasons. 
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Appendix D: Open Discrepancy Reports 


Table D1 provides a list of each NASA Discrepancy Report (DR) that remained open at the end of the SUAV Auto GCAS project. 
An additional 29 DRs were written during the project but were closed by the Configuration Control Board, normally because the problem had been 
confirmed as fixed. The main intent of table D1 is to allow staff of similar future projects to decide whether each item warrants improvement. 
A paraphrased and shortened description for each DR is provided in the table. 

Table Dl. Open Discrepancy Reports. 


DR# 

Title 

Short description and disposition 

Auto GCAS component 

11-125 

TRANSITION TO IDLE 
KEEPS FLYUP ACTIVE 

• When a flyup is engaged, transitioning to IDLE keeps the flyup 
active. 

• Workaround: Click on another mode to transition out of flyup 
mode 

User interface 

11-126 

INTERMITTENT 
CONNECTION BETWEEN 
PHONE AND USER 
INTERFACE 

• User interface timeout on AGCAS connection occurs at random 
times, causing a FAIL mode to be asserted. Frequency is very 
low, but random in nature. 

• Workaround: Click on appropriate mode on user interface to 
resume normal function. 

User interface / smartphone 
software 

11-130 

INAPPROPRIATE FLYUP 
TERMINATION DUE TO 
P-FACTOR 

• Termination of some flyups is delayed longer than necessary. 
Data show that flyups to the right result in delayed termination; 
flyups to the left result in early termination. 

• Recommendation: Future SUAV Auto GCAS projects should 
consider modifying the termination logic to use a straight 
trajectory that is unaffected by P-factor. 

Algorithm on smartphone 

12-108 

FAIL INDICATIONS 

• FAIL indications occurred shortly after flyup initiation on at least 
three test runs. These FAIL indications were somewhat disruptive 
to the normal test flow and degraded the intended test data. On 
later missions the FAIL “timeout” was changed from 0.5 to 5.0 s 
to ensure no test disruption, but 5.0 s may not be the optimal 
setting. 

• Recommendation: Determine optimal FAIL timeout value for 
future Auto GCAS projects. 


12-110 

STREAMLINE CAPABILITY 
FOR PILOT CONTROL 
AFTER AGCAS 
FLYUP/ABORT 

• When the DROID pilot is commanding the from the pilot control 
station at the time a FLYUP is initiated, the pilot does not have a 
single-action command ability to regain control of the DROID. 

• Recommendation: Mechanize system so that a single action 
command by the pilot will regain control after a FLYUP or 
ABORT. 

Ground control van and user 
interface 
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12-111 

AUTOPILOT DID NOT 
RESPOND TO FLYUP 
COMMAND 

• A right FLYUP command was sent but there was no response 
from the autopilot. This occurred only once on the three flights on 
March 29. 

• Recommendation: Additional research as needed to support future 
Auto GCAS development efforts. 

Smartphone to Piccolo II 
interface 

12-112 

ILLOGICAL FLYUP 
TRAJECTORIES IN 
RECORDED DATA 

• The left, straight, and right trajectories recorded at FLYUP 
initiation were all identical. 

• Recommendation: Additional research as needed to support future 
Auto GCAS development efforts. 

Algorithm on smartphone 

12-113 

FLYUP WENT OUTSIDE 
SCAN PATTERN 

• The actual flyup trajectory went outside the scan pattern by 
approximately 50 ft horizontally. The altitude approached 25 ft of 
the TCB, indicating that going outside the scan may have 
contributed to reduced terrain clearance. This run may have been 
influenced by wind changes after FLYUP initiation. 

• Recommendation: Additional research as needed to support future 
Auto GCAS development efforts. 

Algorithm on smartphone 

12-114 

INDECISIVE FLYUP 
TERMINATION 

• Three additional short flyups occurred after termination of the 
first flyup (over total duration of 7 s). Cases with one or two 
additional flyups occurred on other flights. It would be 
appropriate for every flyup to terminate without subsequent 
flyups for at least several seconds. 

• Recommendation: Additional research as needed to support future 
Auto GCAS development efforts. 

Algorithm on smartphone 

12-115 

FLYUP WENT INSIDE SCAN 
PATTERN 

• Flyup was as much as 130 ft inside the scan. Flyups with this 
characteristic pose an increased risk of nuisance potential but are 
unlikely to increase risk of terrain impact. 

• Recommendation: Additional research as needed to support future 
Auto GCAS development efforts. 

Algorithm on smartphone 

12-116 

POSSIBLE LATE FLYUPS 

• The data show that the predicted trajectories were well below the 
buffered terrain for both left and right options. This result implies 
a large jump in the TPA compared to a single frame earlier. 

• Recommendation: Additional research as needed to support future 
Auto GCAS development efforts. 

Algorithm on smartphone 

12-117 

GPS DISCONTINUITIES 

• GPS position discontinuities up to 132 ft occurred (in between 
frames) on several flights. This problem was later traced to a 
known problem in the Piccolo II software version used during 
flight-testing. 

• Recommendation: Update Piccolo II software before future tests 
using the DROID. 

Piccolo II software 

12-118 

AUTOPILOT EXCEEDS 
LIMITS 

• The DROID was able to establish a descent rate over 2500 ft/min 
and a bank angle of almost 50 deg. These values were well in 
excess of expected Piccolo II limits of @ 1000 ft/min and 40 deg 
bank. This problem was later traced to large-amplitude rudder 

Ground control van to 
Piccolo II interface 
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inputs applied by the pilot in the ground cockpit (rudder inputs 
went directly to the control surfaces and were not limited by the 
Piccolo II). 

• Recommendation: Reconfigure rudder pedal commands so 

Piccolo II limits will not be exceeded, or advise pilots on limited 
use of rudder pedals. 


12-120 

NO CAPABILITY FOR 
COCKPIT PILOT TO 
DISENGAGE FLYUPS 

• The ground cockpit pilot could not disengage a flyup and regain 
control (as the design was then implemented). The main impact of 
not implementing this capability was the inability to properly 
conduct Auto GACS nuisance testing. 

• Recommendation: The ideal mechanization would allow a single 
HOT AS action to terminate a flyup in progress and not allow that 
flyup to resume. “New” flyups could occur unless the pilot 
chooses to continue holding the HOTAS. 

Ground control van to user 
interface 

12-121 

ABORT BUTTON 
FUNCTIONALITY 

• The UI ABORT button sends a signal to terminate the current 
flyup but another flyup is almost immediately recalculated and 
performed. 

• Workaround: Instead of clicking on the UI ABORT button, 
change the AGCAS mode to STANDBY or IDLE until ready to 
resume avoidance maneuvers. 

User interface 

12-122 

AGCAS SOFTWARE 
RECORDED REDUNDANT 
LATITUDE AND LONGITUDE 
VALUES IN SMARTPHONE 

• For eight flight-test events the Auto GCAS software recorded 
redundant trajectory prediction latitude and longitude data on the 
smartphone SD card. These cases are related to DR 12-112. 

• Recommendation: Additional research as needed to support future 
Auto GCAS development efforts. 

Algorithm on smartphone 
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